doesn't split legal vector operands. This is necessary because the
type legalization (and therefore, vector splitting) code will be going
away soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72349 91177308-0d34-0410-b5e6-96231b3b80d8
The DAGCombiner created a negative shiftamount, stored in an
unsigned variable. Later the optimizer eliminated the shift entirely as being
undefined.
Example: (srl (shl X, 56) 48). ShiftAmt is 4294967288.
Fix it by checking that the shiftamount is positive, and storing in a signed
variable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72331 91177308-0d34-0410-b5e6-96231b3b80d8
will allow simplifying LegalizeDAG to eliminate type legalization. (I
have a patch to do that, but it's not quite finished; I'll commit it
once it's finished and I've fixed any review comments for this patch.)
See the comment at the beginning of
lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp for more details on the
motivation for this patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72325 91177308-0d34-0410-b5e6-96231b3b80d8
code in preparation for code generation. The main thing it does
is handle the case when eh.exception calls (and, in a future
patch, eh.selector calls) are far away from landing pads. Right
now in practice you only find eh.exception calls close to landing
pads: either in a landing pad (the common case) or in a landing
pad successor, due to loop passes shifting them about. However
future exception handling improvements will result in calls far
from landing pads:
(1) Inlining of rewinds. Consider the following case:
In function @f:
...
invoke @g to label %normal unwind label %unwinds
...
unwinds:
%ex = call i8* @llvm.eh.exception()
...
In function @g:
...
invoke @something to label %continue unwind label %handler
...
handler:
%ex = call i8* @llvm.eh.exception()
... perform cleanups ...
"rethrow exception"
Now inline @g into @f. Currently this is turned into:
In function @f:
...
invoke @something to label %continue unwind label %handler
...
handler:
%ex = call i8* @llvm.eh.exception()
... perform cleanups ...
invoke "rethrow exception" to label %normal unwind label %unwinds
unwinds:
%ex = call i8* @llvm.eh.exception()
...
However we would like to simplify invoke of "rethrow exception" into
a branch to the %unwinds label. Then %unwinds is no longer a landing
pad, and the eh.exception call there is then far away from any landing
pads.
(2) Using the unwind instruction for cleanups.
It would be nice to have codegen handle the following case:
invoke @something to label %continue unwind label %run_cleanups
...
handler:
... perform cleanups ...
unwind
This requires turning "unwind" into a library call, which
necessarily takes a pointer to the exception as an argument
(this patch also does this unwind lowering). But that means
you are using eh.exception again far from a landing pad.
(3) Bugpoint simplifications. When bugpoint is simplifying
exception handling code it often generates eh.exception calls
far from a landing pad, which then causes codegen to assert.
Bugpoint then latches on to this assertion and loses sight
of the original problem.
Note that it is currently rare for this pass to actually do
anything. And in fact it normally shouldn't do anything at
all given the code coming out of llvm-gcc! But it does fire
a few times in the testsuite. As far as I can see this is
almost always due to the LoopStrengthReduce codegen pass
introducing pointless loop preheader blocks which are landing
pads and only contain a branch to another block. This other
block contains an eh.exception call. So probably by tweaking
LoopStrengthReduce a bit this can be avoided.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72276 91177308-0d34-0410-b5e6-96231b3b80d8
the 'constract function dbg thingy'. Rename some methods to make them consistent
with the rest of the methods. Move the 'Emit' methods to the end of the file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72192 91177308-0d34-0410-b5e6-96231b3b80d8
build an integer and cast that to a float. This fixes a crash
caused by trying to split an f32 into two f16's.
This changes the behavior in test/CodeGen/XCore/fneg.ll because that
testcase now triggers a DAGCombine which converts the fneg into an integer
operation. If someone is interested, it's probably possible to tweak
the test to generate an actual fneg.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72162 91177308-0d34-0410-b5e6-96231b3b80d8
function, this could be many, many times. We don't want to re-add variables to
that DIE for each time. We just want to add them once. Check to make sure that
we haven't added them already.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72047 91177308-0d34-0410-b5e6-96231b3b80d8
The following is checked:
* Operand counts: All explicit operands must be present.
* Register classes: All physical and virtual register operands must be
compatible with the register class required by the instruction descriptor.
* Register live intervals: Registers must be defined only once, and must be
defined before use.
The machine code verifier is enabled with the command-line option
'-verify-machineinstrs', or by defining the environment variable
LLVM_VERIFY_MACHINEINSTRS to the name of a file that will receive all the
verifier errors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71918 91177308-0d34-0410-b5e6-96231b3b80d8
logical/sane approach to organizing all of the stuff that goes into writing out
DWARF information. Honestly? even this is too complex for what it's supposed to
be doing.
Trivia: It *looks* like there would be functionality changes, however there aren't!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71821 91177308-0d34-0410-b5e6-96231b3b80d8
