AL is only used for varargs on SysV platforms. Don't forward it on
Windows. This allows control flow guard to set up an extra hidden
parameter in RAX, as described in PR44049.
This also has the effect of freeing up RAX for use in virtual member
pointer thunks, which may also be a nice little code size improvement on
Win64.
Fixes PR44049
Reviewers: ajpaverd, efriedma, hans
Differential Revision: https://reviews.llvm.org/D70413
In order to correctly pass options to LLVM, including options containing
spaces which are used as delimiters for multiple options in
lto_codegen_debug_options, add a new API:
lto_codegen_debug_options_array.
Unfortunately, tools/lto has no testing infrastructure yet, so there are
no tests associated with this patch.
Differential Revision: https://reviews.llvm.org/D70463
I am in another pickle here where if I specify a triple, I get the wrong elf
target arch on the PPC bot (error from the PPC elf Linker). To avoid this I am
going to turn this test off on the PPC bots for now.
Simplify the code by avoiding some state that wasn't being used. The
function-level `Result` was only assigned a value other than `Success`
in the handler for `OPTIONS_BLOCK_ID`, but in that case it also hits an
early return. Remove it at the function-level to make it obvious that
the normal case always returns `Success`.
This is a first pass at Custom lowering for these operations. I also updated some of the vector code where it was obviously easy and straightforward. More work needed in follow up.
This enables these operations to be handled with X87 where special rounding control adjustments are needed to perform a truncate.
Still need to fix Promotion in the target independent code in LegalizeDAG.
llrint/llround split into separate test file because we can't make a strict libcall properly yet either and we need to do that when i64 isn't a legal type.
This does not include any isel support. So we still rely on the mutation in SelectionDAGIsel to remove the strict from this stuff later. Except for the X87 stuff which goes through custom nodes that already had chains.
Differential Revision: https://reviews.llvm.org/D70214
I want this test to run end to end, but I am still having trouble with
missing linkers on the scei-ps4 bot. Will remove this test if it
continues to be a source of brittle failures. Sorry for the noise.
Summary:
expect() forwards its command to sendline(). This can be problematic if the command already contains a newline: sendline() unconditionally adds a newline to the command, which causes the command to run twice (hitting enter in lldb runs the previous command). The expect() helper looks for the prompt and finds the first one, but because the command has run a second time, the buffer will contain the contents of the second time the command ran, causing potential erroneous matching.
Simplify the editline test, which was using different commands to workaround this misunderstanding.
Reviewers: labath
Reviewed By: labath
Subscribers: merge_guards_bot, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70324
This diff adds a new "driver" for llvm-objcopy
which is supposed to emulate the behavior of install-name-tool.
This is a recommit of b5913e6d2 with ubsan issues fixed.
Differential revision: https://reviews.llvm.org/D69146
Test plan: make check-all
This code has never been enabled. While it is tested, it's complicating some refactoring. If we decide to re-implement this, doing it in SimplifyCFG would probably make more sense anyways.
Second Landing Attempt:
Up until now, clang interface stubs has replaced the standard
PP -> C -> BE -> ASM -> LNK pipeline. With this change, it will happen in
conjunction with it. So what when you build your code you will get an
a.out or lib.so as well as an interface stub file.
Example:
clang -shared -o libfoo.so -emit-interface-stubs ...
will generate both a libfoo.so and a libfoo.ifso. The .so file will
contain the code from the standard compilation pipeline and the .ifso
file will contain the ELF stub library.
Differential Revision: https://reviews.llvm.org/D70274
With the widenable condition construct, we have the ability to reason about branches which can be 'widened' (i.e. made to fail more often). We've got a couple o transforms which leverage this. This patch just cleans up the API a bit.
This is prep work for generalizing our definition of a widenable branch slightly. At the moment "br i1 (and A, wc()), ..." is considered widenable, but oddly, neither "br i1 (and wc(), B), ..." or "br i1 wc(), ..." is. That clearly needs addressed, so first, let's centralize the code in one place.
Unswitch (and other loop transforms) like to generate loop exit blocks with unconditional successors, and phi nodes (LCSSA, or simple multiple exiting blocks sharing an exit). Generalize the "likely very rare exit" check slightly to handle this form.
Force `-Werror=strict-prototypes` so that C API tests fail to compile if
we add a non-prototype declaration. This should help avoid regressions
like bddecba4b3 was fixing.
https://reviews.llvm.org/D70285
rdar://problem/57203137
If we partially unswitch a loop, we leave around the (and i1 X, true) or (or i1 X, false) forms. At the moment, this inhibits SCEVs ability to compute trip counts, patch forthcoming.
According to OpenMP 5.0, if clause can be used in simd directive. If
condition in the if clause if false, the non-vectorized version of the
loop must be executed.
Currently, clang emits subprograms for declared functions when the
target debugger or DWARF standard is known to support entry values
(DW_OP_entry_value & the GNU equivalent).
Treat DW_AT_tail_call the same way to allow debuggers to follow cross-TU
tail calls.
Pre-patch debug session with a cross-TU tail call:
```
* frame #0: 0x0000000100000fa4 main`target at b.c:4:3 [opt]
frame #1: 0x0000000100000f99 main`main at a.c:8:10 [opt]
```
Post-patch (note that the tail-calling frame, "helper", is visible):
```
* frame #0: 0x0000000100000fa4 main`target at b.c:4:3 [opt]
frame #1: 0x0000000100000f80 main`helper [opt] [artificial]
frame #2: 0x0000000100000f99 main`main at a.c:8:10 [opt]
```
This was reverted in 5b9a072c because it attached declaration
subprograms to inlinable builtin calls, which interacted badly with the
MergeICmps pass. The fix is to not attach declarations to builtins.
rdar://46577651
Differential Revision: https://reviews.llvm.org/D69743
It turns out that the debug info describing the Sema class is an
appreciable percentage of the total object file size of objects in Sema.
By adding a key function, clang is able to optimize the debug info size
by emitting a forward declaration in TUs that do not define the key
function.
On Windows, with clang-cl, these are the total sizes of object files in
Sema before and after this change, compiling with optimizations and
debug info:
before: 335,012 KB
after: 278,116 KB
delta: -56,896 KB
percent: -17.0%
The effect on link time was negligible, despite having ~56MB less input.
On Linux, with clang, these are the same sizes using DWARF -g and
optimizations:
before: 603,756 KB
after: 515,340 KB
delta: -88,416 KB
percent: -14.6%
I didn't use type units, DWARF-5, fission, or any other special flags.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D70340
Continuous mode is not yet supported on Fuchsia/Windows, however an
error should not be reported unless the user attempted to actually
enable continuous mode.
SUMMARY:
CMVC has a compiler error on the
const uint64_t OffsetToRaw = is64Bit()
? toSection64(Sec)->FileOffsetToRawData
: toSection32(Sec)->FileOffsetToRawData;
while gcc compiler do not have the problem.
I have to change the code to
uint64_t OffsetToRaw;
if (is64Bit())
OffsetToRaw = toSection64(Sec)->FileOffsetToRawData;
else
OffsetToRaw = toSection32(Sec)->FileOffsetToRawData;
Reviewers: Sean Fertile
Subscribers: rupprecht, seiyai,hiraditya
Differential Revision: https://reviews.llvm.org/D70255
A call site parameter description of a memory operand needs to
unambiguously convey the size of the operand to prevent incorrect entry
value evaluation.
Thanks for David Stenberg for pointing this issue out!
Pair up inlined AutoreleaseRV calls with their matching RetainRV or
ClaimRV.
- RetainRV cancels out AutoreleaseRV. Delete both instructions.
- ClaimRV is a peephole for RetainRV+Release. Delete AutoreleaseRV and
replace ClaimRV with Release.
This avoids problems where more aggressive inlining triggers memory
regressions.
This patch is happy to skip over non-callable instructions and non-ARC
intrinsics looking for the pair. It is likely sound to also skip over
opaque function calls, but that's harder to reason about, and it's not
relevant to the goal here: if there's an opaque function call splitting
up a pair, it's very unlikely that a handshake would have happened
dynamically without inlining.
Note that this patch also subsumes the previous logic that looked
backwards from ReleaseRV.
https://reviews.llvm.org/D70370
rdar://problem/46509586
The 1st attempt was reverted because it revealed an existing
bug where we could produce invalid IR (use of value before
definition). That should be fixed with:
rG39de82ecc9c2
The bug manifests as replacing a reduction operand with an undef
value.
The problem appears to be limited to cases where a min/max reduction
has extra uses of the compare operand to the select.
In the general case, we are tracking "ExternallyUsedValues" and
an "IgnoreList" of the reduction operations, but those may not apply
to the final compare+select in a min/max reduction.
For that, we use replaceAllUsesWith (RAUW) to ensure that the new
vectorized reduction values are transferred to all subsequent users.
Differential Revision: https://reviews.llvm.org/D70148
Summary:
In particular, 1- and 2-byte loads and stores ignore the pointer tag
when using SP as the base register.
Reviewers: pcc, ostannard
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70341
Summary:
This also changes the test-release.sh script to build using the monorepo
layout instead of copying sub-projects into llvm/tools or llvm/projects.
Reviewers: jdoerfert, hans
Reviewed By: hans
Subscribers: hans, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70353
This speeds up the build of compiler-rt with an expensive checks enabled clang by an order of
1 or 2 magnitudes on my machine. I was hoping this would also fix the 'large.test' libFuzzer
timeout on the expensive checks bot on green dragon http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/,
but the fuzzer test still takes too long to compile because of other IR/MIR verification inefficiencies.
Differential Revision: https://reviews.llvm.org/D70288
This is an attempt to feature the user-facing resources more
prominently on the LLDB website by calling out the tutorial and the
GDB command map wight on the start page.
I also moved the "Why a new debugger" section to the "Goals"
subpage. Given that LLDB's first release is almost a decade in the
past now, the title is a bit of an anachronism.
Lastly, I moved the Architecture sub-page from "use" to "resources",
since end-users do not care about the source code layout.
Differential Revision: https://reviews.llvm.org/D70449
Now that we have the intrinsics, we can add VLD2/4 and VST2/4 lowering
for MVE. This works the same way as Neon, recognising the load/shuffles
combination and converting them into intrinsics in a pre-isel pass,
which just calls getMaxSupportedInterleaveFactor, lowerInterleavedLoad
and lowerInterleavedStore.
The main difference to Neon is that we do not have a VLD3 instruction.
Otherwise most of the code works very similarly, with just some minor
differences in the form of the intrinsics to work around. VLD3 is
disabled by making isLegalInterleavedAccessType return false for those
cases.
We may need some other future adjustments, such as VLD4 take up half the
available registers so should maybe cost more. This patch should get the
basics in though.
Differential Revision: https://reviews.llvm.org/D69392
SUMMARY:
implement printing out raw section data of xcoff objectfile for llvm-objdump
and option -D --disassemble-all option for llvm-objdump
Reviewers: Sean Fertile
Subscribers: rupprecht, seiyai,hiraditya
Differential Revision: https://reviews.llvm.org/D70255
Avoids a deadlock in "clang/test/Index/crash-recovery-modules.m" when building with the MSVC STL & _ITERATOR_DEBUG_LEVEL == 2 (meaning a DEBUG build)
Differential Revision: https://reviews.llvm.org/D69959
Summary:
The sanitizer symbolizers support printing the function offset
(difference between pc and function start) of a stackframe using the
`%q` format specifier.
Unfortunately this didn't actually work because neither the atos
or dladdr symbolizer set the `AddressInfo::function_offset` field.
This patch teaches both symbolizers to try to compute the function
offset. In the case of the atos symbolizer, atos might not report the
function offset (e.g. it reports a source location instead) so in this
case it fallsback to using `dladdr()` to compute the function offset.
Two test cases are included.
rdar://problem/56695185
Reviewers: kubamracek, yln
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D69549
The CUDA builtin library is apparently compiled in C++ mode, so the
assumption of convergent needs to be made in a typically non-SPMD
language. The functions in the library should still be assumed
convergent. Currently they are not, which is potentially incorrect and
this happens to work after the library is linked.
Reid Kleckner