and xor. The 32-bit move immediates can be hoisted out of loops by machine
LICM but the isel hacks were preventing them.
Instead, let peephole optimization pass recognize registers that are defined by
immediates and the ARM target hook will fold the immediates in.
Other changes include 1) do not fold and / xor into cmp to isel TST / TEQ
instructions if there are multiple uses. This happens when the 'and' is live
out, machine sink would have sinked the computation and that ends up pessimizing
code. The peephole pass would recognize situations where the 'and' can be
toggled to define CPSR and eliminate the comparison anyway.
2) Move peephole pass to after machine LICM, sink, and CSE to avoid blocking
important optimizations.
rdar://8663787, rdar://8241368
llvm-svn: 119548
instructions have to distinguish between lists of single- and double-precision
registers in order for the ASM matcher to do a proper job. In all other
respects, a list of single- or double-precision registers are the same as a list
of GPR registers.
llvm-svn: 119460
over a phi node by applying it to each operand may be wrong if the
operation and the phi node are mutually interdependent (the testcase
has a simple example of this). So only do this transform if it would
be correct to perform the operation in each predecessor of the block
containing the phi, i.e. if the other operands all dominate the phi.
This should fix the FFMPEG snow.c regression reported by İsmail Dönmez.
llvm-svn: 119347
The live range of a register defined by an early clobber starts at the use slot,
not the def slot.
Except when it is an early clobber tied to a use operand. Then it starts at the
def slot like a standard def.
llvm-svn: 119305
live ranges for the spill register are also defined at the use slot instead of
the normal def slot.
This fixes PR8612 for the inline spiller. A use was being allocated to the same
register as a spilled early clobber def.
This problem exists in all the spillers. A fix for the standard spiller is
forthcoming.
llvm-svn: 119182
variable if recursing fails to simplify it.
Factor AliasedSymbol to be a method of MCSymbol.
Update MCAssembler::EvaluateFixup to match the change in
EvaluateAsRelocatableImpl.
Remove the WeakRefExpr hack, as the object writer now sees the weakref with
no extra effort needed.
Nothing else is using MCTargetExpr, but keep it for now.
Now that the ELF writer sees relocations with aliases, handle
.weak foo2
foo2:
.weak bar2
.set bar2,foo2
.quad bar2
the same way gas does and produce a relocation with bar2.
llvm-svn: 119152
This moves most of the isUsed logic to the MCSymbol itself. With this we
get a bit more relaxed about allowing definitions after uses: uses that
don't evaluate their argument immediately (jmp foo) are accepted.
ddunbar, this was the smallest compromise I could think of that lets us
accept gcc (and clang!) assembly.
llvm-svn: 119144
offload the work to hasConstantValue rather than do something more
complicated (such handling mutually recursive phis) because (1) it is
not clear it is worth it; and (2) if it is worth it, maybe such logic
would be better placed in hasConstantValue. Adjust some GVN tests
which are now cleaned up much further (eg: all phi nodes are removed).
llvm-svn: 119043
SimplifyAssociativeOrCommutative) "(A op C1) op C2" -> "A op (C1 op C2)",
which previously was only done if C1 and C2 were constants, to occur whenever
"C1 op C2" simplifies (a la InstructionSimplify). Since the simplifying operand
combination can no longer be assumed to be the right-hand terms, consider all of
the possible permutations. When compiling "gcc as one big file", transform 2
(i.e. using right-hand operands) fires about 4000 times but it has to be said
that most of the time the simplifying operands are both constants. Transforms
3, 4 and 5 each fired once. Transform 6, which is an existing transform that
I didn't change, never fired. With this change, the testcase is now optimized
perfectly with one run of instcombine (previously it required instcombine +
reassociate + instcombine, and it may just have been luck that this worked).
llvm-svn: 119002
2. Fixing several errors in disassembler uncovered by test cases.
3. Fixing invalid encoding of PCMPEQ and PCMPNE uncovered by test cases.
llvm-svn: 118969
2. Parsing .word directive in MBlaze asm parser
3. Fixing hack where memory instructions reversed order of last two parameters
4. Fixing many improperly encoded instructions
5. Support parsing special instructions (MFS,MTS,etc.)
6. Removing unused functions from inst printer
llvm-svn: 118941
support for the case where alignment<value size.
These cases were silently miscompiled before this patch.
Now they are overly verbose -especially storing is- and
any front-end should still avoid misaligned memory
accesses as much as possible. The bit juggling algorithm
added here probably has some room for improvement still.
llvm-svn: 118889
testing for dereferenceable pointers into a helper function,
isDereferenceablePointer. Teach it how to reason about GEPs
with simple non-zero indices.
Also eliminate ArgumentPromtion's IsAlwaysValidPointer,
which didn't check for weak externals or out of range gep
indices.
llvm-svn: 118840
references. For example, this allows gvn to eliminate the load in
this example:
void foo(int n, int* p, int *q) {
p[0] = 0;
p[1] = 1;
if (n) {
*q = p[0];
}
}
llvm-svn: 118714
nodes can be used in loops, this could result in infinite looping
if there is no recursion limit, so add such a limit. It is also
used for the SelectInst case because in theory there could be an
infinite loop there too if the basic block is unreachable.
llvm-svn: 118694
It is only supported for ARM code. Normally Thumb2 code would use DMB instead,
but depending on how the compiler is invoked (e.g., -mattr=-db) that might be
disabled. This prevents a "cannot select MEMBARRIER_MCR" error in that
situation. Radar 8644195
llvm-svn: 118642
to optionally look for constant or local (alloca) memory.
Teach BasicAliasAnalysis::pointsToConstantMemory to look through Select
and Phi nodes, and to support looking for local memory.
Remove FunctionAttrs' PointsToLocalOrConstantMemory function, now that
AliasAnalysis knows all the tricks that it knew.
llvm-svn: 118412
of a select instruction, see if doing the compare with the
true and false values of the select gives the same result.
If so, that can be used as the value of the comparison.
llvm-svn: 118378
different forms of this instruction (movw/movl/movq) which we reported
as being ambiguous. Since they all do the same thing, gas just picks the
one with the shortest encoding. Follow its lead here.
This implements rdar://8208615
llvm-svn: 118362
exposed:
GAS doesn't accept "fcomip %st(1)", it requires "fcomip %st(1), %st(0)"
even though st(0) is implicit in all other fp stack instructions.
Fortunately, there is an alias for fcomip named "fcompi" and gas does
accept the default argument for the alias (boggle!).
As such, switch the canonical form of this instruction to "pi" instead
of "ip". This makes the code generator and disassembler generate pi,
avoiding the gas bug.
llvm-svn: 118356
shift-by-1 instructions, where the asmstring doesn't contain
the implicit 1. It turns out that a bunch of these rotate
instructions were completely broken because they used 1
instead of $1.
This fixes assembly mismatches on "rclb $1, %bl" and friends,
where we used to generate the 3 byte form, we now generate the
proper 2-byte form.
llvm-svn: 118355
floating point stack instructions instead of looking for b/w/l/q.
This fixes issues where we'd accidentally match fistp to fistpl,
when it is in fact an ambiguous instruction.
This changes the behavior of llvm-mc to reject fstp, which was the
correct fix for rdar://8456389:
t.s:1:1: error: ambiguous instructions require an explicit suffix (could be 'fstps', 'fstpl', or 'fstpt')
fstp (%rax)
it also causes us to correctly reject fistp and fist, which addresses
PR8528:
t.s:2:1: error: ambiguous instructions require an explicit suffix (could be 'fistps', or 'fistpl')
fistp (%rax)
^
t.s:3:1: error: ambiguous instructions require an explicit suffix (could be 'fists', or 'fistl')
fist (%rax)
^
Thanks to Ismail Donmez for tracking down the issue here!
llvm-svn: 118346
sequence of loads and stores was being generated to perform the
copy on the x86 targets if the parameter was less than 4 byte
aligned, causing llc to use up vast amounts of memory and time.
Use a "rep movs" form instead. PR7170.
llvm-svn: 118260
all of the different element sizes are pseudo instructions that map down to vext.8 underneath, with
the immediate shifted left to reflect the increased element size.
llvm-svn: 118183
vldr.64 d1, [r0, #-32]
The problem was with how the addressing mode 5 encodes the offsets. This change
makes sure that the way offsets are handled in addressing mode 5 is consistent
throughout the MC code. It involves re-refactoring the "getAddrModeImmOpValue"
method into an "Imm12" and "addressing mode 5" version. But not to worry! The
majority of the duplicated code has been unified.
llvm-svn: 118144
1. Fix pre-ra scheduler so it doesn't try to push instructions above calls to
"optimize for latency". Call instructions don't have the right latency and
this is more likely to use introduce spills.
2. Fix if-converter cost function. For ARM, it should use instruction latencies,
not # of micro-ops since multi-latency instructions is completely executed
even when the predicate is false. Also, some instruction will be "slower"
when they are predicated due to the register def becoming implicit input.
rdar://8598427
llvm-svn: 118135
with immediates up to 16-bits in size. The same logic is applied to other LDR
encodings, e.g. VLDR, but which use a different immediate bit width (8-bits in
VLDR's case). Removing the "12" allows it to be more generic.
llvm-svn: 118094
at more than those which define CPSR. You can have this situation:
(1) subs ...
(2) sub r6, r5, r4
(3) movge ...
(4) cmp r6, 0
(5) movge ...
We cannot convert (2) to "subs" because (3) is using the CPSR set by
(1). There's an analogous situation here:
(1) sub r1, r2, r3
(2) sub r4, r5, r6
(3) cmp r4, ...
(5) movge ...
(6) cmp r1, ...
(7) movge ...
We cannot convert (1) to "subs" because of the intervening use of CPSR.
llvm-svn: 117950
aliases installed and working. They now work when the
matched pattern and the result instruction have exactly
the same operand list.
This is now enough for us to define proper aliases for
movzx and movsx, implementing rdar://8017633 and PR7459.
Note that we do not accept instructions like:
movzx 0(%rsp), %rsi
GAS accepts this instruction, but it doesn't make any
sense because we don't know the size of the memory
operand. It could be 8/16/32 bits.
llvm-svn: 117901
in their asmstring. Fix the two x86 "NOREX" instructions that have them.
If these comments are important, the instlowering stuff can print them.
llvm-svn: 117897
consider it to be readonly. In fact, don't even consider it to be
readonly if it does a volatile load from an AllocaInst either (it
is debatable as to whether readonly would be correct or not in this
case; play safe for the moment). This fixes PR8279.
llvm-svn: 117783
There were a number of issues to fix up here:
* The "device" argument of the llvm.memory.barrier intrinsic should be
used to distinguish the "Full System" domain from the "Inner Shareable"
domain. It has nothing to do with using DMB vs. DSB instructions.
* The compiler should never need to emit DSB instructions. Remove the
ARMISD::SYNCBARRIER node and also remove the instruction patterns for DSB.
* Merge the separate DMB/DSB instructions for options only used for the
disassembler with the default DMB/DSB instructions. Add the default
"full system" option ARM_MB::SY to the ARM_MB::MemBOpt enum.
* Add a separate ARMISD::MEMBARRIER_MCR node for subtargets that implement
a data memory barrier using the MCR instruction.
* Fix up encodings for these instructions (except MCR).
I also updated the tests and added a few new ones to check for DMB options
that were not currently being exercised.
llvm-svn: 117756
just
.type foo,@object
will produce an undefined reference to foo. On the other hand, a file with
just
.weakref bar, foo
will not. It is somewhat hard to support both in MC since both statements
should create the symbols. It should be possible if we really need to by
adding to the flags, but hopefully that is not necessary.
With this patch we do not produce a undefined reference in any of those cases.
The assembly file needs an actual use for the undefined reference to be
present.
This is in preparation for a patch implementing .weakref.
llvm-svn: 117735
This code had previously used 2*N, where N is the mask length, to represent
undef. That is not safe because the shufflevector operands may have more
than N elements -- they don't have to match the result type.
llvm-svn: 117721
Allow splats even if they don't match either of the original shuffles,
possibly due to undef entries in the shuffles masks. Radar 8597790.
Also fix some 80-column violations.
llvm-svn: 117719
operand and one of them has a single use that is a live out copy, favor the
one that is live out. Otherwise it will be difficult to eliminate the copy
if the instruction is a loop induction variable update. e.g.
BB:
sub r1, r3, #1
str r0, [r2, r3]
mov r3, r1
cmp
bne BB
=>
BB:
str r0, [r2, r3]
sub r3, r3, #1
cmp
bne BB
This fixed the recent 256.bzip2 regression.
llvm-svn: 117675
With Python-2.4, Reader::read64 always returns (unexpected) long integer.
FileCheck detects failure on test/MC/MachO among '0' and '0L'.
CentOS5(aka RHEL5 clone) provides python-2.4.
llvm-svn: 117637
* If we have a M or a G, reject sections without the type
* Only parse the flag specific arguments if we have M or G
* Parse the corresponding arguments for M and G
We ignore the G arguments and flag for now.
llvm-svn: 117608
- For now, loads of [r, r] addressing mode is the same as the
[r, r lsl/lsr/asr #] variants. ARMBaseInstrInfo::getOperandLatency() should
identify the former case and reduce the output latency by 1.
- Also identify [r, r << 2] case. This special form of shifter addressing mode
is "free".
llvm-svn: 117519
elements than the result vector type. So, when an instruction like:
%8 = shufflevector <2 x float> %4, <2 x float> %7, <4 x i32> <i32 1, i32 0, i32 3, i32 2>
is translated to a DAG, each operand is changed to a concat_vectors node that appends 2 undef elements. That is:
shuffle [a,b], [c,d] is changed to:
shuffle [a,b,u,u], [c,d,u,u]
That's probably the right thing for x86 but for NEON, we'd much rather have:
shuffle [a,b,c,d], undef
Teach the DAG combiner how to do that transformation for ARM. Radar 8597007.
llvm-svn: 117482
sense, when the instruction takes the 16-bit ax register or m16 memory
location. These changes to llvm-mc matches what the darwin assembler
allows for these instructions. Done differently than in r117031 that
caused a valgrind error which was later reverted.
llvm-svn: 117433
The SPU ABI does not mention v64, and all examples
in C suggest v128 are treated similarily to arrays,
we use array alignment for v64 too. This makes the
alignment of e.g. [2 x <2 x i32>] behave "intuitively"
and similar to as if the elements were e.g. i32s.
This also makes an "unaligned store" test to be
aligned, with different (but functionally equivalent)
code generated.
llvm-svn: 117360
do not double-count the duplicate instructions by counting once from the
beginning and again from the end. Keep track of where the duplicates from
the beginning ended and don't go past that point when counting duplicates
at the end. Radar 8589805.
This change causes one of the MC/ARM/simple-fp-encoding tests to produce
different (better!) code without the vmovne instruction being tested.
I changed the test to produce vmovne and vmoveq instructions but moving
between register files in the opposite direction. That's not quite the same
but predicated versions of those instructions weren't being tested before,
so at least the test coverage is not any worse, just different.
llvm-svn: 117333
it isn't unreachable and should not be zapped. The check for the entry block
was missing in one case: a block containing a unwind instruction. While there,
do some small cleanups: "M" is not a great name for a Function* (it would be
more appropriate for a Module*), change it to "Fn"; use Fn in more places.
llvm-svn: 117224
weren't properly reflecting the OperandSize attribute
of the instruction leading to improper decoding of
certain instructions with the 66H prefix. Also added
a test case for this.
llvm-svn: 117084
sense, when the instruction takes the 16-bit ax register or m16 memory
location. These changes to llvm-mc matches what the darwin assembler allows
for these instructions. Also added the missing flex (without the wait prefix)
and ud2a as an alias to ud2 (still to add ud2b).
llvm-svn: 117031
1. A delay slot filler that searches for valid instructions
to fill the delay slot with. Previously NOPs would always
be inserted into delay slots.
2. Support for MC based instruction printer added.
3. Support for MC based machine code generation and ELF
file generation. ELF file generation does not yet
completely work as much of the ELF support infrastructure
is still x86/x86-64 specific.
4. General clean up of the MBlaze backend code. Much of the
tablegen code has been cleanup and simplified.
Bug Fixes:
1. Removed duplicate periods from subtarget feature descriptions.
2. Many of the instructions had bad machine code information
in the tablegen files. Much of this has been fixed.
llvm-svn: 116986
- Initial register pressure in the loop should be all the live defs into the
loop. Not just those from loop preheader which is often empty.
- When an instruction is hoisted, update register pressure from loop preheader
to the original BB.
- Treat only use of a virtual register as kill since the code is still SSA.
llvm-svn: 116956
The failures in r116753 r116756 were caused by a python issue -
Python likes to append 'L' suffix to stringified numbers if the number
is larger than a machine int. Unfortunately, this causes a divergence of
behavior between 32 and 64 bit python versions.
I re-crafted elf-dump/common_dump to take care of these issues by:
1. always printing 0x (makes for easy sed/regex)
2. always print fixed length (exactly 2 + numBits/4 digits long)
by mod ((2^numBits) - 1)
3. left-padded with '0'
There is a residual common routine that is also used by
macho-dump (dataToHex) , so I left the 'section_data' test values alone.
llvm-svn: 116823
"long latency" enough to hoist even if it may increase spilling. Reloading
a value from spill slot is often cheaper than performing an expensive
computation in the loop. For X86, that means machine LICM will hoist
SQRT, DIV, etc. ARM will be somewhat aggressive with VFP and NEON
instructions.
- Enable register pressure aware machine LICM by default.
llvm-svn: 116781
word forms and suffixed versions to match the darwin assembler in 32-bit and
64-bit modes. This is again for use just with assembly source for llvm-mc .
llvm-svn: 116773
does normal initialization and normal chaining. Change the default
AliasAnalysis implementation to NoAlias.
Update StandardCompileOpts.h and friends to explicitly request
BasicAliasAnalysis.
Update tests to explicitly request -basicaa.
llvm-svn: 116720
be more complete. These are only expected to be used by llvm-mc with assembly
source so there is no pattern, [], in the .td files. Most are being added to
X86InstrInfo.td as Chris suggested and only comments about register uses are
added. Suggestions welcome on the .td changes as I'm not sure on every detail
of the x86 records. More missing instructions will be coming.
llvm-svn: 116716
The old algorithm inserted a 'rotqmbyi' instruction which was
both redundant and wrong - it made shufb select bytes from the
wrong end of the input quad.
llvm-svn: 116701
have been printed with the "S" modifier after the predicate. With ARM's
unified syntax, they are supposed to go in the other order. We fixed this
for Thumb when we switched to unified syntax but missed changing it for
ARM. Apparently we don't generate these instructions often because no one
noticed until now. Thanks to Bill Wendling for the testcase!
llvm-svn: 116563
here. The f32 in FCONSTS is handled as a double instead of a float in the
code. So the encoding of the immediate into the instruction isn't exactly in
line with the documentation in that regard. But given that we know it's handled
as a double, it doesn't cause any harm.
llvm-svn: 116471
logic to use the new APInt methods. Among other things this
implements rdar://8501501 - llvm.smul.with.overflow.i32 should constant fold
which comes from "clang -ftrapv", originally brought to my attention from PR8221.
llvm-svn: 116457
alignment for PPC32/64, avoiding some masking operations.
llvm-gcc expands vaarg inline instead of using the instruction
so it has never hit this.
llvm-svn: 116168
1. Cortex-A8 load / store multiplies can only issue on ALU0.
2. Eliminate A8_Issue, A8_LSPipe will correctly limit the load / store issues.
3. Correctly model all vld1 and vld2 variants.
llvm-svn: 116134
concept level stuff at this point, but it is generally working for those
instructions that know how to map the operands.
This patch fills in the register operands for add/sub/or/etc instructions
and adds the conditional execution predicate encoding.
llvm-svn: 116112
callee-saved registers at the end of the lists. Also prefer to avoid using
the low registers that are in register subclasses required by certain
instructions, so that those registers will more likely be available when needed.
This change makes a huge improvement in spilling in some cases. Thanks to
Jakob for helping me realize the problem.
Most of this patch is fixing the testsuite. There are quite a few places
where we're checking for specific registers. I changed those to wildcards
in places where that doesn't weaken the tests. The spill-q.ll and
thumb2-spill-q.ll tests stopped spilling with this change, so I added a bunch
of live values to force spills on those tests.
llvm-svn: 116055
reapply: reimplement the second half of the or/add optimization. We should now
with no changes. Turns out that one missing "Defs = [EFLAGS]" can upset things
a bit.
llvm-svn: 116040
only end up emitting LEA instead of OR. If we aren't able to promote
something into an LEA, we should never be emitting it as an ADD.
Add some testcases that we emit "or" in cases where we used to produce
an "add".
llvm-svn: 116026
Owen Anderson