1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-30 15:32:52 +01:00
Commit Graph

92119 Commits

Author SHA1 Message Date
Akira Hatanaka
af33bc35ec [mips] Factor out unaligned store lowering code.
llvm-svn: 182050
2013-05-16 20:45:17 +00:00
Hal Finkel
4f0a332c93 Fix cpu on test CodeGen/PowerPC/ctrloop-fp64.ll
We need ppc instead of generic to override native features on ppc machines.

llvm-svn: 182049
2013-05-16 20:28:05 +00:00
Jack Carter
0c75cd3c10 Mips assembler: Add TwoOperandConstraint definitions
This patch removes alias definition for addiu $rs,$imm 
and instead uses the TwoOperandAliasConstraint field in 
the ArithLogicI instruction class. 

This way all instructions that inherit ArithLogicI class 
have the same macro defined. 

The usage examples are added to test files.

Patch by Vladimir Medic

llvm-svn: 182048
2013-05-16 20:24:27 +00:00
Jack Carter
27313685a3 Mips td file formatting: white space and long lines
llvm-svn: 182047
2013-05-16 20:08:49 +00:00
Rafael Espindola
afa5fae8eb More addFrameMove test coverage.
llvm-svn: 182046
2013-05-16 20:00:45 +00:00
Hal Finkel
80fddc9af7 Create an new preheader in PPCCTRLoops to avoid counter register clobbers
Some IR-level instructions (such as FP <-> i64 conversions) are not chained
w.r.t. the mtctr intrinsic and yet may become function calls that clobber the
counter register. At the selection-DAG level, these might be reordered with the
mtctr intrinsic causing miscompiles. To avoid this situation, if an existing
preheader has instructions that might use the counter register, create a new
preheader for the mtctr intrinsic. This extra block will be remerged with the
old preheader at the MI level, but will prevent unwanted reordering at the
selection-DAG level.

llvm-svn: 182045
2013-05-16 19:58:38 +00:00
Akira Hatanaka
ba455f200e [mips] Test case for r182042. Add comment.
llvm-svn: 182044
2013-05-16 19:57:23 +00:00
Akira Hatanaka
fe7cc5cbd7 [mips] Fix instruction selection pattern for sint_to_fp node to avoid emitting an
invalid instruction sequence.

Rather than emitting an int-to-FP move instruction and an int-to-FP conversion
instruction during instruction selection, we emit a pseudo instruction which gets
expanded post-RA. Without this change, register allocation can possibly insert a
floating point register move instruction between the two instructions, which is not
valid according to the ISA manual.

mtc1 $f4, $4         # int-to-fp move instruction.
mov.s $f2, $f4       # move contents of $f4 to $f2.
cvt.s.w $f0, $f2     # int-to-fp conversion.

llvm-svn: 182042
2013-05-16 19:48:37 +00:00
Rafael Espindola
a2af7d8def More test coverage for addFrameMove.
llvm-svn: 182041
2013-05-16 19:44:40 +00:00
Jack Carter
8986125dda Mips assembler: Add branch macro definitions
This patch adds bnez and beqz instructions which represent alias definitions for bne and beq instructions as follows:
bnez $rs,$imm => bne $rs,$zero,$imm
beqz $rs,$imm => beq $rs,$zero,$imm

The corresponding test cases are added.

Patch by Vladimir Medic

llvm-svn: 182040
2013-05-16 19:40:19 +00:00
Benjamin Kramer
d971be891d DAGCombine: Also shrink eq compares where the constant is exactly as large as the smaller type.
if ((x & 255) == 255)

before: movzbl  %al, %eax
        cmpl  $255, %eax

after:  cmpb  $-1, %al
llvm-svn: 182038
2013-05-16 18:47:58 +00:00
Akira Hatanaka
8513e9139f [mips] Fix indentation.
llvm-svn: 182036
2013-05-16 18:42:42 +00:00
Akira Hatanaka
8857b3a45c [mips] Delete unused enum value.
llvm-svn: 182035
2013-05-16 18:40:12 +00:00
Jakob Stoklund Olesen
4d48e01000 Add TargetRegisterInfo::getCoveringLanes().
This lane mask provides information about which register lanes
completely cover super-registers. See the block comment before
getCoveringLanes().

llvm-svn: 182034
2013-05-16 18:03:08 +00:00
Ulrich Weigand
7b22c7a38a [PowerPC] Use true offset value in "memrix" machine operands
This is the second part of the change to always return "true"
offset values from getPreIndexedAddressParts, tackling the
case of "memrix" type operands.

This is about instructions like LD/STD that only have a 14-bit
field to encode immediate offsets, which are implicitly extended
by two zero bits by the machine, so that in effect we can access
16-bit offsets as long as they are a multiple of 4.

The PowerPC back end currently handles such instructions by
carrying the 14-bit value (as it will get encoded into the
actual machine instructions) in the machine operand fields
for such instructions.  This means that those values are
in fact not the true offset, but rather the offset divided
by 4 (and then truncated to an unsigned 14-bit value).

Like in the case fixed in r182012, this makes common code
operations on such offset values not work as expected.
Furthermore, there doesn't really appear to be any strong
reason why we should encode machine operands this way.

This patch therefore changes the encoding of "memrix" type
machine operands to simply contain the "true" offset value
as a signed immediate value, while enforcing the rules that
it must fit in a 16-bit signed value and must also be a
multiple of 4.

This change must be made simultaneously in all places that
access machine operands of this type.  However, just about
all those changes make the code simpler; in many cases we
can now just share the same code for memri and memrix
operands.

llvm-svn: 182032
2013-05-16 17:58:02 +00:00
Hal Finkel
7daa616e35 PPC32 cannot form counter loops around i64 FP conversions
On PPC32, i64 FP conversions are implemented using runtime calls (which clobber
the counter register). These must be excluded.

llvm-svn: 182023
2013-05-16 16:52:41 +00:00
Rafael Espindola
eb3034b91f Add a triple to the test to try to fix the windows bots.
llvm-svn: 182022
2013-05-16 16:48:46 +00:00
Rafael Espindola
d2b872cd1b More addFrameMove test coverage.
llvm-svn: 182021
2013-05-16 16:34:38 +00:00
Bill Schmidt
edb2d94d45 Use new CHECK-DAG support to stabilize CodeGen/PowerPC/recipest.ll
While testing some experimental code to add vector-scalar registers to
PowerPC, I noticed that a couple of independent instructions were
flipped by the scheduler.  The new CHECK-DAG support is perfect for
avoiding this problem.

llvm-svn: 182020
2013-05-16 16:15:18 +00:00
Rafael Espindola
379ba8a86e Add more addFrameMove test coverage.
llvm-svn: 182019
2013-05-16 16:09:54 +00:00
Aaron Ballman
42af887d8c Fixing a 64-bit conversion warning in MSVC.
llvm-svn: 182018
2013-05-16 16:03:36 +00:00
Rafael Espindola
7dd7b264b7 Add more test coverage for addFrameMove.
llvm-svn: 182017
2013-05-16 15:18:50 +00:00
Rafael Espindola
4c7120e048 Remove dead calls to addFrameMove.
Without a PROLOG_LABEL present, the cfi instructions are never printed.

llvm-svn: 182016
2013-05-16 15:08:37 +00:00
Ulrich Weigand
08228b8354 [PowerPC] Report true displacement value from getPreIndexedAddressParts
DAGCombiner::CombineToPreIndexedLoadStore calls a target routine to
decompose a memory address into a base/offset pair.  It expects the
offset (if constant) to be the true displacement value in order to
perform optional additional optimizations; in particular, to convert
other uses of the original pointer into uses of the new base pointer
after pre-increment.

The PowerPC implementation of getPreIndexedAddressParts, however,
simply calls SelectAddressRegImm, which returns a TargetConstant.
This value is appropriate for encoding into the instruction, but
it is not always usable as true displacement value:

- Its type is always MVT::i32, even on 64-bit, where addresses
  ought to be i64 ... this causes the optimization to simply
  always fail on 64-bit due to this line in DAGCombiner:

      // FIXME: In some cases, we can be smarter about this.
      if (Op1.getValueType() != Offset.getValueType()) {

- Its value is truncated to an unsigned 16-bit value if negative.
  This causes the above opimization to generate wrong code.

This patch fixes both problems by simply returning the true
displacement value (in its original type).  This doesn't
affect any other user of the displacement.

llvm-svn: 182012
2013-05-16 14:53:05 +00:00
Rafael Espindola
16c10c628f Add more addFrameMove test coverage.
llvm-svn: 182011
2013-05-16 14:51:26 +00:00
Rafael Espindola
0daf590030 Extend test to check the .cfi instructions.
I am about to refactor the calls to addFrameMove and some of the ppc
ones were not being tested.

llvm-svn: 182009
2013-05-16 14:30:09 +00:00
Richard Sandiford
cb335bb295 [SystemZ] Tweak register array comment
llvm-svn: 182007
2013-05-16 13:39:02 +00:00
Benjamin Kramer
c2c24d044d Relax CHECK-NEXTs a bit to cope with atom's return nop padding.
llvm-svn: 181999
2013-05-16 11:46:50 +00:00
Evgeniy Stepanov
bce1a20d13 [msan] Switch TLS globals to initial-exec model.
They are always defined in the main executable.

llvm-svn: 181994
2013-05-16 09:14:05 +00:00
Patrik Hagglund
a0ea76e714 Removed unused variable, detected by gcc
-Wunused-but-set-variable. Leftover from r181979.

llvm-svn: 181993
2013-05-16 08:37:22 +00:00
Rafael Espindola
537821c785 Delete dead code.
llvm-svn: 181982
2013-05-16 04:59:17 +00:00
Rafael Espindola
24bf7876c2 Don't call addFrameMove on XCore.
getExceptionHandlingType is not ExceptionHandling::DwarfCFI on xcore, so
etFrameInstructions is never called. There is no point creating cfi
instructions if they are never used.

llvm-svn: 181979
2013-05-16 04:16:25 +00:00
Richard Smith
3995413b20 Respect the 'nobuiltin' attribute when determining if a call is to a memory builtin.
llvm-svn: 181978
2013-05-16 04:12:04 +00:00
Rafael Espindola
554870d776 Extend test for better coverage.
Without this change nothing was covering this addFrameMove:

// For 64-bit SVR4 when we have spilled CRs, the spill location
// is SP+8, not a frame-relative slot.
if (Subtarget.isSVR4ABI()
    && Subtarget.isPPC64()
    && (PPC::CR2 <= Reg && Reg <= PPC::CR4)) {
  MachineLocation CSDst(PPC::X1, 8);
  MachineLocation CSSrc(PPC::CR2);
  MMI.addFrameMove(Label, CSDst, CSSrc);
  continue;
}

llvm-svn: 181976
2013-05-16 03:48:50 +00:00
Rafael Espindola
92a3518a62 Removed dead code.
llvm-svn: 181975
2013-05-16 03:34:58 +00:00
Lang Hames
b0c9552559 Fix PBQP graph iterator typedefs.
llvm-svn: 181973
2013-05-16 02:20:41 +00:00
Reed Kotler
fb71c30979 Patch number 2 for mips16/32 floating point interoperability stubs.
This creates stubs that help Mips32 functions call Mips16 
functions which have floating point parameters that are normally passed
in floating point registers.
 

llvm-svn: 181972
2013-05-16 02:17:42 +00:00
Derek Schuff
8af06f2ba6 Revert "Support unaligned load/store on more ARM targets"
This reverts r181898.

llvm-svn: 181944
2013-05-15 23:07:43 +00:00
Eli Bendersky
c0e010b564 Remove dead code.
This method is not being used/tested anywhere.

llvm-svn: 181943
2013-05-15 22:41:28 +00:00
Arnold Schwaighofer
63eb047996 LoopVectorize: Move call of canHoistAllLoads to canVectorizeWithIfConvert
We only want to check this once, not for every conditional block in the loop.

No functionality change (except that we don't perform a check redudantly
anymore).

llvm-svn: 181942
2013-05-15 22:38:14 +00:00
Rafael Espindola
e1f815ebd9 Delete dead code.
llvm-svn: 181941
2013-05-15 22:27:35 +00:00
David Majnemer
71b69a2eb9 Set an explicit triple for this test.
This allows the test to correctly check symbol names.

llvm-svn: 181939
2013-05-15 22:23:21 +00:00
Hal Finkel
ae8f6158eb undef setjmp in PPCCTRLoops
Trying to unbreak the VS build by copying some undef code from
Utils/LowerInvoke.cpp.

llvm-svn: 181938
2013-05-15 22:20:24 +00:00
David Majnemer
8ce4c34d1d X86: Remove redundant test instructions
Increase the number of instructions LLVM recognizes as setting the ZF
flag. This allows us to remove test instructions that redundantly
recalculate the flag.

llvm-svn: 181937
2013-05-15 22:03:08 +00:00
Bill Wendling
29e9e36da8 Use proper syntax.
llvm-svn: 181930
2013-05-15 21:38:12 +00:00
Hal Finkel
91bd48d046 Implement PPC counter loops as a late IR-level pass
The old PPCCTRLoops pass, like the Hexagon pass version from which it was
derived, could only handle some simple loops in canonical form. We cannot
directly adapt the new Hexagon hardware loops pass, however, because the
Hexagon pass contains a fundamental assumption that non-constant-trip-count
loops will contain a guard, and this is not always true (the result being that
incorrect negative counts can be generated). With this commit, we replace the
pass with a late IR-level pass which makes use of SE to calculate the
backedge-taken counts and safely generate the loop-count expressions (including
any necessary max() parts). This IR level pass inserts custom intrinsics that
are lowered into the desired decrement-and-branch instructions.

The most fragile part of this new implementation is that interfering uses of
the counter register must be detected on the IR level (and, on PPC, this also
includes any indirect branches in addition to function calls). Also, to make
all of this work, we need a variant of the mtctr instruction that is marked
as having side effects. Without this, machine-code level CSE, DCE, etc.
illegally transform the resulting code. Hopefully, this can be improved
in the future.

This new pass is smaller than the original (and much smaller than the new
Hexagon hardware loops pass), and can handle many additional cases correctly.
In addition, the preheader-creation code has been copied from LoopSimplify, and
after we decide on where it belongs, this code will be refactored so that it
can be explicitly shared (making this implementation even smaller).

The new test-case files ctrloop-{le,lt,ne}.ll have been adapted from tests for
the new Hexagon pass. There are a few classes of loops that this pass does not
transform (noted by FIXMEs in the files), but these deficiencies can be
addressed within the SE infrastructure (thus helping many other passes as well).

llvm-svn: 181927
2013-05-15 21:37:41 +00:00
Hal Finkel
29ce39fc2e Fix legalization of SETCC with promoted integer intrinsics
If the input operands to SETCC are promoted, we need to make sure that we
either use the promoted form of both operands (or neither); a mixture is not
allowed. This can happen, for example, if a target has a custom promoted
i1-returning intrinsic (where i1 is not a legal type). In this case, we need to
use the promoted form of both operands.

This change only augments the behavior of the existing logic in the case where
the input types (which may or may not have already been legalized) disagree,
and should not affect existing target code because this case would otherwise
cause an assert in the SETCC operand promotion code.

This will be covered by (essentially all of the) tests for the new PPCCTRLoops
infrastructure.

llvm-svn: 181926
2013-05-15 21:37:27 +00:00
Bill Wendling
da386b9c50 Add lldb and polly to the projects to tag.
llvm-svn: 181925
2013-05-15 21:36:46 +00:00
Derek Schuff
962654973c Fix miscompile due to StackColoring incorrectly merging stack slots (PR15707)
IR optimisation passes can result in a basic block that contains:

  llvm.lifetime.start(%buf)
  ...
  llvm.lifetime.end(%buf)
  ...
  llvm.lifetime.start(%buf)

Before this change, calculateLiveIntervals() was ignoring the second
lifetime.start() and was regarding %buf as being dead from the
lifetime.end() through to the end of the basic block.  This can cause
StackColoring to incorrectly merge %buf with another stack slot.

Fix by removing the incorrect Starts[pos].isValid() and
Finishes[pos].isValid() checks.

Just doing:
      Starts[pos] = Indexes->getMBBStartIdx(MBB);
      Finishes[pos] = Indexes->getMBBEndIdx(MBB);
unconditionally would be enough to fix the bug, but it causes some
test failures due to stack slots not being merged when they were
before.  So, in order to keep the existing tests passing, treat LiveIn
and LiveOut separately rather than approximating the live ranges by
merging LiveIn and LiveOut.

This fixes PR15707.
Patch by Mark Seaborn.

llvm-svn: 181922
2013-05-15 21:15:09 +00:00
Rafael Espindola
5ef2f39b92 Cleanup relocation sorting for ELF.
We want the order to be deterministic on all platforms. NAKAMURA Takumi
fixed that in r181864. This patch is just two small cleanups:

* Move the function to the cpp file. It is only passed to array_pod_sort.
* Remove the ppc implementation which is now redundant

llvm-svn: 181910
2013-05-15 18:22:01 +00:00