| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 179954
|
| |
|
|
| |
llvm-svn: 179937
|
| |
|
|
|
|
| |
parameter attribute 'returned', which is taken advantage of in target-independent tail call opportunity detection and in ARM call lowering (when placed on an integral first parameter).
llvm-svn: 179925
|
| |
|
|
|
|
| |
iterations of extractelement/insertelement indirection
llvm-svn: 179924
|
| |
|
|
| |
llvm-svn: 179906
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When matching a compare with a subtract where the arguments of the compare are
swapped w.r.t. the arguments of the subtract, we need to negate the predicates
(or CR bit indices) of the users. This, however, is not the same as inverting
the predicate (negating LT -> GT, but inverting LT -> GE, for example). The ARM
backend seems to do this correctly, but when I adapted the code for the PPC
backend, I introduced an error in this logic.
Comparison optimization is now enabled again by default.
llvm-svn: 179899
|
| |
|
|
|
|
| |
Based on the patch by David Nadlinger!
llvm-svn: 179889
|
| |
|
|
| |
llvm-svn: 179888
|
| |
|
|
|
|
| |
for a function that cannot produce a compact unwind encoding.
llvm-svn: 179887
|
| |
|
|
|
|
| |
This reverts commit r179836 as it seems to have caused test failures.
llvm-svn: 179840
|
| |
|
|
|
|
|
|
|
|
| |
Adding another CU-wide list, in this case of imported_modules (since they
should be relatively rare, it seemed better to add a list where each element
had a "context" value, rather than add a (usually empty) list to every scope).
This takes care of DW_TAG_imported_module, but to fully address PR14606 we'll
need to expand this to cover DW_TAG_imported_declaration too.
llvm-svn: 179836
|
| |
|
|
| |
llvm-svn: 179830
|
| |
|
|
| |
llvm-svn: 179828
|
| |
|
|
|
|
|
| |
This seems to cause a stage-2 LLVM compile failure (by crashing TableGen); do
I'm disabling this for now.
llvm-svn: 179807
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many PPC instructions have a so-called 'record form' which stores to a specific
condition register the result of comparing the result of the instruction with
zero (always as a signed comparison). For integer operations on PPC64, this is
always a 64-bit comparison.
This implementation is derived from the implementation in the ARM backend;
there are some differences because PPC condition registers are allocatable
virtual registers (although the record forms always use a specific one), and we
look for a matching subtraction instruction after the compare (but before the
first use) in addition to before it.
llvm-svn: 179802
|
| |
|
|
|
|
|
|
| |
available.
This pattern started popping up in vectorized min/max reductions.
llvm-svn: 179797
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In X86FastISel::X86SelectStore(), improperly aligned stores are rejected and
handled by the DAG-based ISel. However, X86FastISel::X86SelectLoad() makes
no such requirement. There doesn't appear to be an x86 architectural
correctness issue with allowing potentially unaligned store instructions.
This patch removes this restriction.
Patch by Jim Stichnot.
llvm-svn: 179774
|
| |
|
|
| |
llvm-svn: 179751
|
| |
|
|
|
|
|
|
|
| |
for the sdiv/srem/udiv/urem bitcode instructions. This is done for the i8,
i16, and i32 types, as well as i64 for the x86_64 target.
Patch by Jim Stichnoth
llvm-svn: 179715
|
| |
|
|
| |
llvm-svn: 179686
|
| |
|
|
| |
llvm-svn: 179621
|
| |
|
|
|
|
| |
I intend to extend the test with more offset folding checks
llvm-svn: 179620
|
| |
|
|
| |
llvm-svn: 179619
|
| |
|
|
| |
llvm-svn: 179591
|
| |
|
|
| |
llvm-svn: 179582
|
| |
|
|
|
|
|
|
| |
Instead of emitting config values in a predefined order, the code
emitter will now emit a 32-bit register index followed by the 32-bit
config value.
llvm-svn: 179546
|
| |
|
|
| |
llvm-svn: 179545
|
| |
|
|
| |
llvm-svn: 179544
|
| |
|
|
| |
llvm-svn: 179532
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes an ABI bug for non-Darwin PPC64. For the callee-saved condition
registers, the spill location is specified relative to the stack pointer (SP +
8). However, this is not relative to the SP after the new stack frame is
established, but instead relative to the caller's stack pointer (it is stored
into the linkage area of the parent's stack frame).
So, like with the link register, we don't directly spill the CRs with other
callee-saved registers, but just mark them to be spilled during prologue
generation.
In practice, this reverts r179457 for PPC64 (but leaves it in place for PPC32).
llvm-svn: 179500
|
| |
|
|
|
|
| |
Test case by llvm-stress.
llvm-svn: 179477
|
| |
|
|
|
|
| |
For when 16 TB just isn't enough.
llvm-svn: 179474
|
| |
|
|
|
|
|
| |
This is the default model for non-PIC 64-bit code. It supports
text+data+bss linked anywhere in the low 16 TB of the address space.
llvm-svn: 179473
|
| |
|
|
|
|
|
| |
Constant pool entries are accessed exactly the same way as global
variables.
llvm-svn: 179471
|
| |
|
|
|
|
| |
This fixes the pic32 code model for SPARC v9.
llvm-svn: 179469
|
| |
|
|
|
|
|
| |
Currently, only abs32 and pic32 are implemented. Add a test case for
abs32 with 64-bit code. 64-bit PIC code is currently broken.
llvm-svn: 179463
|
| |
|
|
|
|
|
|
|
|
| |
For functions that need to spill CRs, and have dynamic stack allocations, the
value of the SP during the restore is not what it was during the save, and so
we need to use the FP in these cases (as for all of the other spills and
restores, but the CR restore has a special code path because its reserved slot,
like the link register, is specified directly relative to the adjusted SP).
llvm-svn: 179457
|
| |
|
|
|
|
| |
The order of copies depends on queue order, which is not very stable.
llvm-svn: 179456
|
| |
|
|
| |
llvm-svn: 179455
|
| |
|
|
| |
llvm-svn: 179453
|
| |
|
|
|
|
|
|
|
|
|
| |
The register allocator expects minimal physreg live ranges. Schedule
physreg copies accordingly. This is slightly tricky when they occur in
the middle of the scheduling region. For now, this is handled by
rescheduling the copy when its associated instruction is
scheduled. Eventually we may instead bundle them, but only if we can
preserve the bundles as parallel copies during regalloc.
llvm-svn: 179449
|
| |
|
|
| |
llvm-svn: 179434
|
| |
|
|
| |
llvm-svn: 179422
|
| |
|
|
|
|
| |
instructions.
llvm-svn: 179421
|
| |
|
|
| |
llvm-svn: 179420
|
| |
|
|
| |
llvm-svn: 179361
|
| |
|
|
| |
llvm-svn: 179354
|
| |
|
|
|
|
|
|
|
|
| |
When debugging performance regressions we often ask ourselves if the regression
that we see is due to poor isel/sched/ra or due to some micro-architetural
problem. When comparing two code sequences one good way to rule out front-end
bottlenecks (and other the issues) is to force code alignment. This pass adds
a flag that forces the alignment of all of the basic blocks in the program.
llvm-svn: 179353
|
| |
|
|
| |
llvm-svn: 179322
|
| |
|
|
|
|
| |
These changes are based on commit responses for r179135.
llvm-svn: 179315
|