| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 122259
|
|
|
|
|
|
|
|
| |
ARM (and other 32-bit-only) targets support for i8 and i16 overflow
multiplies. The generated code isn't great, but this at least fixes
CodeGen/Generic/overflow.ll when running on ARM hosts.
llvm-svn: 122221
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Imagine we see:
EFLAGS = inst1
EFLAGS = inst2 FLAGS
gpr = inst3 EFLAGS
Previously, we would refuse to schedule inst2 because it clobbers
the EFLAGS of the predecessor. However, it also uses the EFLAGS
of the predecessor, so it is safe to emit. SDep edges ensure that
the right order happens already anyway.
This fixes 2 testsuite crashes with the X86 patch I'm going to
commit next.
llvm-svn: 122211
|
|
|
|
| |
llvm-svn: 122209
|
|
|
|
| |
llvm-svn: 122208
|
|
|
|
| |
llvm-svn: 122193
|
|
|
|
|
|
|
| |
enough to teach it that ADDE(0,0) is known 0 except the
low bit, for example.
llvm-svn: 122191
|
|
|
|
|
|
|
| |
isel is *required* to split the edge. PHI values get evaluated
on the edge, not in their predecessor block.
llvm-svn: 122170
|
|
|
|
|
|
|
| |
BUILD_VECTOR operands where the element type is not legal. I had previously
changed this code to insert TRUNCATE operations, but that was just wrong.
llvm-svn: 122102
|
|
|
|
|
|
|
| |
code for the case where 32-bit divide by constant is
turned into 64-bit multiply by constant. 8771012.
llvm-svn: 122090
|
|
|
|
|
|
| |
Radar 8776599
llvm-svn: 122018
|
|
|
|
|
|
| |
a wider mul if the wider mul is legal.
llvm-svn: 121848
|
|
|
|
|
|
| |
result, the top bits are truncated off anyway, just use SRL.
llvm-svn: 121846
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when the wider type is legal. This allows us to compile:
define zeroext i16 @test1(i16 zeroext %x) nounwind {
entry:
%div = udiv i16 %x, 33
ret i16 %div
}
into:
test1: # @test1
movzwl 4(%esp), %eax
imull $63551, %eax, %eax # imm = 0xF83F
shrl $21, %eax
ret
instead of:
test1: # @test1
movw $-1985, %ax # imm = 0xFFFFFFFFFFFFF83F
mulw 4(%esp)
andl $65504, %edx # imm = 0xFFE0
movl %edx, %eax
shrl $5, %eax
ret
Implementing rdar://8760399 and example #4 from:
http://blog.regehr.org/archives/320
We should implement the same thing for [su]mul_hilo, but I don't
have immediate plans to do this.
llvm-svn: 121696
|
|
|
|
| |
llvm-svn: 121662
|
|
|
|
|
|
|
| |
catch this here rather than later after accessing uninitialized memory
etc. Fires when compiling the testcase in PR8237.
llvm-svn: 121635
|
|
|
|
|
|
| |
Necessary for byval support on ARM. Radar 7662569.
llvm-svn: 121412
|
|
|
|
| |
llvm-svn: 121356
|
|
|
|
| |
llvm-svn: 121293
|
|
|
|
|
|
|
|
| |
zextOrTrunc(), and APSInt methods extend(), extOrTrunc() and new method
trunc(), to be const and to return a new value instead of modifying the
object in place.
llvm-svn: 121120
|
|
|
|
|
|
| |
message instead of creating DBG_VALUE for undefined value in reg0.
llvm-svn: 121059
|
|
|
|
| |
llvm-svn: 120910
|
|
|
|
|
|
| |
setAllBits(), setBit(unsigned), etc.
llvm-svn: 120564
|
|
|
|
|
|
|
|
|
|
|
| |
legalization time. Since at legalization time there is no mapping from
SDNode back to the corresponding LLVM instruction and the return
SDNode is target specific, this requires a target hook to check for
eligibility. Only x86 and ARM support this form of sibcall optimization
right now.
rdar://8707777
llvm-svn: 120501
|
|
|
|
|
|
| |
and use this to disable a specific optimization. Patch by Micah Villmow!
llvm-svn: 120435
|
|
|
|
| |
llvm-svn: 120413
|
|
|
|
| |
llvm-svn: 120298
|
|
|
|
| |
llvm-svn: 120235
|
|
|
|
| |
llvm-svn: 119990
|
|
|
|
|
|
|
| |
This currently only catches the most basic case, a two-case switch, but can be
extended later.
llvm-svn: 119964
|
|
|
|
| |
llvm-svn: 119903
|
|
|
|
|
|
|
|
|
|
|
| |
so don't claim they are. They are allocated using DAG.getNode, so attempts
to access MemSDNode fields results in reading off the end of the allocated
memory. This fixes crashes with "llc -debug" due to debug code trying to
print MemSDNode fields for these barrier nodes (since the crashes are not
deterministic, use valgrind to see this). Add some nasty checking to try
to catch this kind of thing in the future.
llvm-svn: 119901
|
|
|
|
|
|
| |
but not complicated enough to merit another test.
llvm-svn: 119898
|
|
|
|
| |
llvm-svn: 119875
|
|
|
|
|
|
|
| |
DAGCombine from making an illegal transformation of bitcast of a scalar to a
vector into a scalar_to_vector.
llvm-svn: 119819
|
|
|
|
|
|
| |
not anyext(select). Spotted by Frits van Bommel.
llvm-svn: 119739
|
|
|
|
|
|
|
|
|
|
| |
if the extension types were not the same. The result was that if you
fed a select with sext and zext loads, as in the testcase, then it
would get turned into a zext (or sext) of the select, which is wrong
in the cases when it should have been an sext (resp. zext). Reported
and diagnosed by Sebastien Deldon.
llvm-svn: 119728
|
|
|
|
|
|
|
|
| |
memset; we may need it to decide between MOVAPS and MOVUPS
later. Adjust a test that was looking for wrong code.
PR 3866 / 8675131.
llvm-svn: 119605
|
|
|
|
| |
llvm-svn: 119590
|
|
|
|
|
|
|
| |
easier to debug, and to avoid complications when the CFG changes
in the middle of the instruction selection process.
llvm-svn: 119382
|
|
|
|
| |
llvm-svn: 118913
|
|
|
|
|
|
|
|
|
| |
catastrophic compilation time in the event of unreasonable LLVM
IR. Code quality is a separate issue--someone upstream needs to do a
better job of reducing to llvm.memcpy. If the situation can be reproduced with
any supported frontend, then it will be a separate bug.
llvm-svn: 118904
|
|
|
|
| |
llvm-svn: 118896
|
|
|
|
| |
llvm-svn: 118789
|
|
|
|
|
|
| |
in order to fold it into a load.
llvm-svn: 118471
|
|
|
|
|
|
| |
{i64, i64} from matching i128.
llvm-svn: 118465
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
be used
to perform the copy, which may be of lots of memory [*]. It would be good if the
fall-back code generated something reasonable, i.e. did the copy in a loop, rather
than vast numbers of loads and stores. Add a note about this. Currently target
specific code seems to always kick in so this is more of a theoretical issue rather
than a practical one now that X86 has been fixed.
[*] It's amazing how often people pass mega-byte long arrays by copy...
llvm-svn: 118275
|
|
|
|
|
|
| |
just do it earlier too.
llvm-svn: 118195
|
|
|
|
|
|
|
| |
with a SimpleValueType, while an EVT supports equality and
inequality comparisons with SimpleValueType.
llvm-svn: 118169
|
|
|
|
|
|
|
|
|
|
| |
value type, so there is no point in passing it around using
an EVT. Use the simpler MVT everywhere. Rather than trying
to propagate this information maximally in all the code that
using the calling convention stuff, I chose to do a mainly
low impact change instead.
llvm-svn: 118167
|