If there is a store after the load node, then there is a chain, which means
that there is another user. Thus, asking hasOneUser would fail. Instead we
ask hasNUsesOfValue on the 'data' value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131183 91177308-0d34-0410-b5e6-96231b3b80d8
intrinsic call. This prevents it from being reordered so that it appears
*before* the setjmp intrinsic (thus making it completely useless).
<rdar://problem/9409683>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131174 91177308-0d34-0410-b5e6-96231b3b80d8
at the start of basic blocks to their common predecessor. It's actually quite
common (e.g. about 50 times in JM/lencod) and has shown to be a nice code size
benefit. e.g.
pushq %rax
testl %edi, %edi
jne LBB0_2
## BB#1:
xorb %al, %al
popq %rdx
ret
LBB0_2:
xorb %al, %al
callq _foo
popq %rdx
ret
=>
pushq %rax
xorb %al, %al
testl %edi, %edi
je LBB0_2
## BB#1:
callq _foo
LBB0_2:
popq %rdx
ret
rdar://9145558
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131172 91177308-0d34-0410-b5e6-96231b3b80d8
Still to do:
- Allow replacing / removing passes (infrastructure there, just needs an infrastructure exposed)
- Defining sets of passes to be added or removed as a group
- Extending the support to allow user-defined groups of optimisations
- Allow plugins to be specified for loading automatically (e.g. from plugins.conf or some similar mechanism)
Reviewed by Nick Lewycky.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131155 91177308-0d34-0410-b5e6-96231b3b80d8
test case; I've only seen this on a release branch, and I can't get it
to reproduce on trunk. rdar://problem/7662569
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131152 91177308-0d34-0410-b5e6-96231b3b80d8
this clang will use .debug_frame in, for example,
clang -g -c -m32 test.c
This matches gcc's behaviour. It looks like .debug_frame is a bit bigger
than .eh_frame, but has the big advantage of not being allocated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131140 91177308-0d34-0410-b5e6-96231b3b80d8
DWARF stuff also gets fixed up by ELFARMAsmBackend::ApplyFixup(),
but the offset is not guaranteed to be mod 4 == 0 as in text/data.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131137 91177308-0d34-0410-b5e6-96231b3b80d8
The previous invalidation missed the alias interference caches.
Also add a stats counter for the number of repaired ranges.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131133 91177308-0d34-0410-b5e6-96231b3b80d8
It can happen that a live debug variable is the last use of a sub-register, and
the register allocator will pick a larger register class for the virtual
register. If the allocated register doesn't support the sub-register index,
just use %noreg for the debug variables instead of asserting.
In PR9872, a debug variable ends up in the sub_8bit_hi part of a GR32_ABCD
register. The register is split and one part is inflated to GR32 and assigned
%ESI because there are no more normal uses of sub_8bit_hi.
Since %ESI doesn't have that sub-register, substPhysReg asserted. Now it will
simply insert a %noreg instead, and the debug variable will be marked
unavailable in that range.
We don't currently have a way of saying: !"value" is in bits 8-15 of %ESI, I
don't know if DWARF even supports that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131073 91177308-0d34-0410-b5e6-96231b3b80d8
the smaller encoding and this cuts 270336 bytes from a release version of
clang and 1246272 bytes from a debug build.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131067 91177308-0d34-0410-b5e6-96231b3b80d8
