| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 188626
|
| |
|
|
|
|
|
|
| |
allocated by setupterm. Without this, some folks are seeing leaked
memory whenever this routine is called more than once. Thanks to Craig
Topper for the report.
llvm-svn: 188615
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes SCEVExpander so that it does not create multiple distinct induction
variables for duplicate PHI entries. Specifically, given some code like this:
do.body6: ; preds = %do.body6, %do.body6, %if.then5
%end.0 = phi i8* [ undef, %if.then5 ], [ %incdec.ptr, %do.body6 ], [ %incdec.ptr, %do.body6 ]
...
Note that it is legal to have multiple entries for a basic block so long as the
associated value is the same. So the above input is okay, but expanding an
AddRec in this loop could produce code like this:
do.body6: ; preds = %do.body6, %do.body6, %if.then5
%indvar = phi i64 [ %indvar.next, %do.body6 ], [ %indvar.next1, %do.body6 ], [ 0, %if.then5 ]
%end.0 = phi i8* [ undef, %if.then5 ], [ %incdec.ptr, %do.body6 ], [ %incdec.ptr, %do.body6 ]
...
%indvar.next = add i64 %indvar, 1
%indvar.next1 = add i64 %indvar, 1
And this is not legal because there are two PHI entries for %do.body6 each with
a distinct value.
Unfortunately, I don't have an in-tree test case.
llvm-svn: 188614
|
| |
|
|
|
|
|
|
| |
next value. This avoids crashes due to invalidation.
Patch by Joey Gouly.
llvm-svn: 188605
|
| |
|
|
|
|
| |
Spotted by Nick Lewycky!
llvm-svn: 188599
|
| |
|
|
|
| |
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 188598
|
| |
|
|
|
| |
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 188597
|
| |
|
|
|
| |
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 188596
|
| |
|
|
|
|
|
|
| |
Ongoing 'make the verifier happy' improvements to ARM fast-isel.
rdar://12594152
llvm-svn: 188595
|
| |
|
|
|
|
|
|
|
|
| |
Properly constrain the operand register class for instructions used
in [sz]ext expansion. Update more tests to use the verifier now that
we're getting the register classes correct.
rdar://12594152
llvm-svn: 188594
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Teach the generic instruction selection helper functions to constrain
the register classes of their input operands. For non-physical register
references, the generic code needs to be careful not to mess that up
when replacing references to result registers. As the comment indicates
for MachineRegisterInfo::replaceRegWith(), it's important to call
constrainRegClass() first.
rdar://12594152
llvm-svn: 188593
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Lots of machine verifier errors result from using a plain GPR regclass
for incoming argument copies. A more restrictive rGPR class is more
appropriate since it more accurately represents what's happening, plus
it lines up better with isel later on so the verifier is happier.
Reduces the number of ARM fast-isel tests not running with the verifier
enabled by over half.
rdar://12594152
llvm-svn: 188592
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This regards how mips16 is viewed. It's not really a target type but
there has always been a target for it in the td files. It's more properly
-mcpu=mips32 -mattr=+mips16 . This is how clang treats it but we have
always had the -mcpu=mips16 which I probably should delete now but it will
require updating all the .ll test cases for mips16. In this case it changed
how we decide if we have a count bits instruction and whether instruction
lowering should then expand ctlz. Now that we have dual mode compilation,
-mattr=+mips16 really just indicates the inital processor mode that
we are compiling for. (It is also possible to have -mcpu=64 -mattr=+mips16
but as far as I know, nobody has even built such a processor, though there
is an architecture manual for this).
llvm-svn: 188586
|
| |
|
|
|
|
|
| |
Clang doesn't support the MSVC __cpuid intrinsic yet, and fixing that is
blocked on some fairly complicated issues.
llvm-svn: 188584
|
| |
|
|
|
|
|
|
| |
record type after construction
Plus a type cleanup & minor fix to enumerate members of declarations.
llvm-svn: 188577
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
safe on PPC32 SVR4 ABI
[Patch and following text by Mark Minich; committing on his behalf.]
There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).
In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:
Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.
My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.
This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.
llvm-svn: 188573
|
| |
|
|
|
|
|
|
|
| |
If an ELF relocation is pointed at an absolute address, it will have a symbol ID of zero.
RuntimeDyldELF::processRelocationRef was not previously handling this case, and was instead trying to handle it as a section-relative fixup.
I think this is the right fix here, but my elf-fu is poor on some of the more exotic platforms, so I'd appreciate it if anyone with greater knowledge could verify this.
llvm-svn: 188572
|
| |
|
|
|
|
| |
string to UTF-8.
llvm-svn: 188566
|
| |
|
|
| |
llvm-svn: 188565
|
| |
|
|
| |
llvm-svn: 188563
|
| |
|
|
|
|
|
| |
Fixes two recent piglit regressions with radeonsi.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 188559
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The logic in SIInsertWaits::getHwCounts() only really made sense for SMRD
instructions, and trying to shoehorn it into handling DS_WRITE_B32 caused
it to corrupt the encoding of that by clobbering the first operand with
the second one.
Undo that damage and only apply the SMRD logic to that.
Fixes some derivates related piglit regressions with radeonsi.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 188558
|
| |
|
|
| |
llvm-svn: 188557
|
| |
|
|
| |
llvm-svn: 188556
|
| |
|
|
| |
llvm-svn: 188555
|
| |
|
|
| |
llvm-svn: 188554
|
| |
|
|
|
|
|
|
|
|
| |
address.
This unbreaks PIC with fast isel on ELF targets (PR16717). The output matches
what GCC and SDag do for PIC but may not cover all of the many flavors of PIC
that exist.
llvm-svn: 188551
|
| |
|
|
|
|
|
|
| |
Thumb2 literal loads use an offset encoding which allows for
negative zero. This fixes parsing and encoding so that #-0
is correctly processed. The parser represents #-0 as INT32_MIN.
llvm-svn: 188549
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are many Thumb instructions which take 12-bit immediates encoded in a special
8-byte value + 4-byte rotator form. Not all numbers are represented, and it's legal
to transform an assembly instruction to be able to encode the immediate.
For example: AND and BIC are complementary instructions; one can switch the AND
to a BIC as long as the immediate is complemented.
The intent is to switch one instruction into its complementary one when the immediate
cannot be encoded in the form requested in the original assembly and when the
complementary immediate is encodable.
The patch addresses two issues:
1. definition of t2SOImmNot immediate - it has to check that the orignal value is
not encoded naturally
2. t2AND and t2BIC instruction aliases which should use the Thumb2 SOImm operand
rather than the ARM one.
llvm-svn: 188548
|
| |
|
|
|
|
| |
It would also make sense to use it for memchr; I'm working on that now.
llvm-svn: 188547
|
| |
|
|
| |
llvm-svn: 188546
|
| |
|
|
| |
llvm-svn: 188544
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Generalize r188163 to cope with return types other than MVT::i32, just
as the existing visitMemCmpCall code did. I've split this out into a
subroutine so that it can be used for other upcoming patches.
I also noticed that I'd used the wrong API to record the out chain.
It's a load that uses DAG.getRoot() rather than getRoot(), so the out
chain should go on PendingLoads. I don't have a testcase for that because
we don't do any interesting scheduling on z yet.
llvm-svn: 188540
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r188163 used CLC to implement memcmp. Code that compares the result
directly against zero can test the CC value produced by CLC, but code
that needs an integer result must use IPM. The sequence I'd used was:
ipm <reg>
sll <reg>, 2
sra <reg>, 30
but I'd forgotten that this inverts the order, so that CC==1 ("less")
becomes an integer greater than zero, and CC==2 ("greater") becomes
an integer less than zero. This sequence should only be used if the
CLC arguments are reversed to compensate. The problem then is that
the branch condition must also be reversed when testing the CLC
result directly.
Rather than do that, I went for a different sequence that works with
the natural CLC order:
ipm <reg>
srl <reg>, 28
rll <reg>, <reg>, 31
One advantage of this is that it doesn't clobber CC. A disadvantage
is that any sign extension to 64 bits must be done separately,
rather than being folded into the shifts.
llvm-svn: 188538
|
| |
|
|
|
|
| |
files.
llvm-svn: 188537
|
| |
|
|
|
|
| |
v8i64.
llvm-svn: 188534
|
| |
|
|
|
|
|
| |
This reverts commit a6a39ced095c2f453624ce62c4aead25db41a18f.
This is the wrong version of this fix.
llvm-svn: 188523
|
| |
|
|
|
|
|
|
|
| |
The SIInsertWaits pass was overwriting the first operand (gds bit) of
DS_WRITE_B32 with the second operand (value to write). This meant that
any time the value to write was stored in an odd number VGPR, the gds
bit would be set causing the instruction to write to GDS instead of LDS.
llvm-svn: 188522
|
| |
|
|
|
| |
Tested-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 188521
|
| |
|
|
|
| |
Tested-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 188520
|
| |
|
|
|
| |
Tested-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 188519
|
| |
|
|
|
| |
Tested-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 188518
|
| |
|
|
|
| |
Tested-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 188517
|
| |
|
|
|
| |
Tested-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 188516
|
| |
|
|
|
| |
Tested-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 188515
|
| |
|
|
|
|
|
|
|
|
|
| |
When both constants are positive or both constants are negative,
InstCombine already simplifies comparisons like this, but when
it's exactly zero and -1, the operand sorting ends up reversed
and the pattern fails to match. Handle that special case.
Follow up for rdar://14689217
llvm-svn: 188512
|
| |
|
|
|
|
|
|
| |
empty sequence is the first key/value in a map which is itself in a sequence.
Patch with help from Nick Kledzik.
llvm-svn: 188508
|
| |
|
|
|
|
|
| |
This path wasn't tested before without a datalayout,
so add some more tests and re-run with and without one.
llvm-svn: 188507
|
| |
|
|
| |
llvm-svn: 188506
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
same way as X86_64_GOT relocations. The 'Load' part of GOTLoad is just an
optimization hint for the linker anyway, and can be safely ignored.
This patch also fixes some minor issues with the relocations introduced while
processing an X86_64_GOT[Load]: the addend for the GOT entry should always be
zero, and the addend for the replacement relocation at the original offset
should be the same as the addend of the relocation being replaced.
I haven't come up with a good way of testing this yet, but I'm working on it.
This fixes <rdar://problem/14651564>.
llvm-svn: 188499
|