When a the Apple link editor builds a kext bundle file type and the
value of the -miphoneos-version-min argument is significantly current
(like 11.0) then the (__TEXT,__text) section is changed to the
(__TEXT_EXEC,__text) section. So it would be nice for llvm-nm to
show symbols in that section with a type of T instead of the generic
type of S for some section other than text, data, etc.
rdar://36262205
llvm-svn: 323836
"path" is too generic name for -L or --library-path because a lot of
linker options take paths as arguments. This change renames the option
to avoid confusion.
Differential Revision: https://reviews.llvm.org/D42705
llvm-svn: 323833
Initialize the default value of SymbolFileDWARF uuid with
the appropriately shifted DW_INVALID_OFFSET constant.
This change fixes the collision in the computation of DIE uid
(inside DIERef::GetUID) and incorrect CompileUnit lookup
(because of the misleading cu_offset value).
Test plan: make check-lldb
Differential revision: https://reviews.llvm.org/D42563
llvm-svn: 323832
- If ReqdWorkGroupSize is present it must have all elements >=1.
- If MaxFlatWorkGroupSize must be consistent with ReqdWorkGroupSize.
- Remove FixedWorkGroupSize as now equivalent to ReqdWorkGroupSize.
llvm-svn: 323829
This change updates the Fuchsia-specific code to use the C++ friendly
duration expressions and flips on the building of
libclang_rt.fuzzer-x86_64.a and similar for Fuchsia. Given that
compiler-rt doesn't build on Fuchsia, test have been run by explicitly
building the library and linking it against
lib/fuzzer/tests/FuzzerUnittest.cpp.
Differential Revision: https://reviews.llvm.org/D42670
llvm-svn: 323828
Sometimes users do not specify data layout in LLVM assembly and let llc set the
data layout by target triple after loading the LLVM assembly.
Currently the parser checks alloca address space no matter whether the LLVM
assembly contains data layout definition, which causes false alarm since the
default data layout does not contain the correct alloca address space.
The parser also calls verifier to check debug info and updating invalid debug
info. Currently there is no way to let the verifier to check debug info only.
If the verifier finds non-debug-info issues the parser will fail.
For llc, the fix is to remove the check of alloca addr space in the parser and
disable updating debug info, and defer the updating of debug info and
verification to be after setting data layout of the IR by target.
For other llvm tools, since they do not override data layout by target but
instead can override data layout by a command line option, an argument for
overriding data layout is added to the parser. In cases where data layout
overriding is necessary for the parser, the data layout can be provided by
command line.
Differential Revision: https://reviews.llvm.org/D41832
llvm-svn: 323826
Summary: ThinLTO may skip object for other reasons, e.g. if there is no summary.
Reviewers: pcc, eugenis
Subscribers: mehdi_amini, inglorion, eraman, llvm-commits
Differential Revision: https://reviews.llvm.org/D42514
llvm-svn: 323818
Strings which contain garbage data can trigger an exception in the XUnit
plugin at the UTF-8 decode step because the decode is strict. Use a lax
mode to avoid an exception.
See: https://ci.swift.org/job/oss-lldb-incremental-osx/780
llvm-svn: 323817
Summary:
This is exposed during ThinLTO compilation, when we import an alias by
creating a clone of the aliasee. Without this fix the debug type is
unnecessarily cloned and we get a duplicate, undoing the uniquing.
Fixes PR36089.
Reviewers: mehdi_amini, pcc
Subscribers: eraman, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D41669
llvm-svn: 323813
Passing -minimize to dsymutil prevents the emission of .debug_inlines,
.debug_pubnames, and .debug_pubtypes in favor of the Apple accelerator
tables.
The actual check in the DWARF linker was added in r323655. This patch
simply enables it.
Differential revision: https://reviews.llvm.org/D42688
llvm-svn: 323812
Without the patch !if() is only evaluated if it's used directly.
If it's passed through more than one level of class inheritance,
we end up with a reference to an anonymous record with unresolved
references to the original arguments !if may have used.
The root cause of the problem is that TernOpInit::isComplete()
was always returning false and that prevented use of the folded
value of !if() as an initializer for the record at the next level
of inheritance.
Differential Revision: https://reviews.llvm.org/D42695
llvm-svn: 323807
This patch is the result of a discussion on lldb-dev, see
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013111.html for
background.
For each test (should be eventually: each test configuration) a
separate build directory is created and we execute
make VPATH=$srcdir/path/to/test -C $builddir/path/to/test -f $srcdir/path/to/test/Makefile -I $srcdir/path/to/test
In order to make this work all LLDB tests need to be updated to find
the executable in the test build directory, since CWD still points at
the test's source directory, which is a requirement for unittest2.
Although we have done extensive testing, I'm expecting that this first
attempt will break a few bots. Please DO NOT HESITATE TO REVERT this
patch in order to get the bots green again. We will likely have to
iterate on this some more.
Differential Revision: https://reviews.llvm.org/D42281
llvm-svn: 323803
Previously an empty CPU string was passed to the LTO engine which
resulted in a generic CPU for which certain features like NOPL were
disabled. This fixes that.
Patch by Pratik Bhatu!
llvm-svn: 323801
Summary:
It was a copy-paste typo, sorting only to the 90th percentile twice.
Now, it only sorts the array prefix once, and extracts what we need.
Reviewers: dberris, kpw, eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42690
llvm-svn: 323800
Instructions like memd(r0+##global+1) are legal as long as the entire
address is properly aligned. Assuming that "global" is aligned at an
8-byte boundary, the expression "global+1" appears to be misaligned.
Handle such cases in HexagonConstExtenders, and make sure that any non-
extended offsets generated are still aligned accordingly.
llvm-svn: 323799
This reverts r323562, since it wasn't actually necessary. Constant-
extended offsets do not need to be aligned, as long as the effective
address is aligned.
Keep the testcase, with a modification which checks that such offsets
are not unnecessarily avoided.
llvm-svn: 323798
Similar to D42437, XOP supports variable shift for v16i8/v8i16/v4i32/v2i64 types.
Differential Revision: https://reviews.llvm.org/D42526
llvm-svn: 323797
Summary:
This is in preparation for platforms where `SANITIZER_SUPPORTS_WEAK_HOOKS` is 0.
They require a default implementation.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D42557
llvm-svn: 323795
Mark more opcodes as hasExtraSrcRegAllocReq so that their operands will
be marked as not renamable, to avoid copy forwarding violating the
constraint that only one operand may use the constant bus.
These changes fix a few mis-compiles when copy forwarding is enabled in
MachineCopyPropagation by D41835 (and were reviewed as part of that change).
llvm-svn: 323794
Based on a profile, a couple of hot spots were identified in the
main type merging loop. The code was simplified, a few loops
were re-arranged, and some outlined functions were inlined. This
speeds up type merging by a decent amount, shaving around 3-4 seconds
off of a 40 second link in my test case.
Differential Revision: https://reviews.llvm.org/D42559
llvm-svn: 323790
-amdgpu-waitcnt-forcezero={1|0} Force all waitcnt instrs to be emitted as s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
-amdgpu-waitcnt-forceexp=<n> Force emit a s_waitcnt expcnt(0) before the first <n> instrs
-amdgpu-waitcnt-forcelgkm=<n> Force emit a s_waitcnt lgkmcnt(0) before the first <n> instrs
-amdgpu-waitcnt-forcevm=<n> Force emit a s_waitcnt vmcnt(0) before the first <n> instrs
This patch was pushed ( abb190fd51cd2f9a9eef08c024e109f7f7e909fc ), which caused a buildbot failure, reverted ( 6227480d74da507cf8e1b4bcaffbdb9fb875b4b8 ), and then updated to fix buildbot failures (this patch).
Differential Revision: https://reviews.llvm.org/D40091
llvm-svn: 323788
That's what we really need to link the CUDA plugin against,
not the CUDA runtime API in CUDA_LIBRARIES! While the latter
comes with the CUDA SDK, the Driver API is installed with
the kernel driver and there is at most one per system. As
fallback we can use the stubs library distributed with the
CUDA SDK for linking.
Differential Revision: https://reviews.llvm.org/D42643
llvm-svn: 323787
Kevin Enderby