Even if there's no mode switch performed, the .code directive should still
be sent to the output streamer. Otherwise, for example, an output asm stream
is not equivalent to the input stream which generated it (a dependency on
the input target triple arm vs. thumb is introduced which was not originally
there).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139155 91177308-0d34-0410-b5e6-96231b3b80d8
init.trampoline and adjust.trampoline intrinsics, into two intrinsics
like in GCC. While having one combined intrinsic is tempting, it is
not natural because typically the trampoline initialization needs to
be done in one function, and the result of adjust trampoline is needed
in a different (nested) function. To get around this llvm-gcc hacks the
nested function lowering code to insert an additional parent variable
holding the adjust.trampoline result that can be accessed from the child
function. Dragonegg doesn't have the luxury of tweaking GCC code, so it
stored the result of adjust.trampoline in the memory GCC set aside for
the trampoline itself (this is always available in the child function),
and set up some new memory (using an alloca) to hold the trampoline.
Unfortunately this breaks Go which allocates trampoline memory on the
heap and wants to use it even after the parent has exited (!). Rather
than doing even more hacks to get Go working, it seemed best to just use
two intrinsics like in GCC. Patch mostly by Sanjoy Das.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139140 91177308-0d34-0410-b5e6-96231b3b80d8
instructions are more aligned than the CPU requires, and adds some additional
directives, to follow in future patches. Patch by David Meyer!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139125 91177308-0d34-0410-b5e6-96231b3b80d8
- Drop support for X >u 0, it's equivalent to X != 0 and should be canonicalized into the latter.
- Add X < 1 -> unlikely, which is what instcombine canonicalizes X <= 0 into.
- Add X > -1 -> likely, which is what instcombine canonicalizes X >= 0 into.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139110 91177308-0d34-0410-b5e6-96231b3b80d8
edis shared library in the Makefile build, also stop building it in the
CMake build.
Patch by arrowdodger!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139108 91177308-0d34-0410-b5e6-96231b3b80d8
call. The call may be in the same BB as the landingpad instruction. If that's
the case, then inserting the loads after the landingpad inst, but before the
extractvalues, causes undefined behavior.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139088 91177308-0d34-0410-b5e6-96231b3b80d8
If we have a chain of zext -> assert_zext -> zext -> use, the first zext would get simplified away because of the later zext, and then the later zext would get simplified away because of the assert. The solution is to teach SimplifyDemandedBits that assert_zext demands all of the high bits of its input, rather than only those demanded by its users. No testcase because the only example I have manifests as llvm-gcc miscompiling LLVM, and I haven't found a smaller case that reproduces this problem.
Fixes <rdar://problem/10063365>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139059 91177308-0d34-0410-b5e6-96231b3b80d8
The explanation about a 0 argument being materialized as xor is no
longer valid. Rematerialization will check if EFLAGS is live before
clobbering it.
The code produced by X86TargetLowering::EmitLoweredSelect does not
clobber EFLAGS.
This causes one less testb instruction to be generated in the cmov.ll
test case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139057 91177308-0d34-0410-b5e6-96231b3b80d8
