| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
(copyFromParts/copyToParts).
llvm-svn: 132649
|
| |
|
|
|
|
|
|
|
| |
(only happens when using the -promote-elements option).
The correct legalization order is to first try to promote element. Next, we try
to widen vectors.
llvm-svn: 132648
|
| |
|
|
|
|
|
|
|
| |
of reserved registers.
Use RegisterClassInfo in RABasic as well. This slightly changes som
allocation orders because RegisterClassInfo puts CSR aliases last.
llvm-svn: 132581
|
| |
|
|
|
|
|
|
| |
Previously, these aliases would be ordered alphabetically. (BH, BL)
Print out the computed allocation orders.
llvm-svn: 132580
|
| |
|
|
| |
llvm-svn: 132559
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When compiling a program with lots of small functions like
483.xalancbmk, this makes RAFast 11% faster.
Add some comments to clarify the difference between unallocatable and
reserved registers. It's quite subtle.
The fast register allocator depends on EFLAGS' not being allocatable on
x86. That way it can completely avoid tracking liveness, and it won't
mind when there are multiple uses of a single def.
llvm-svn: 132514
|
| |
|
|
|
|
| |
Part of rdar://9119939
llvm-svn: 132510
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some register classes are only used for instruction operand constraints.
They should never be used for virtual registers. Previously, those
register classes were given an empty allocation order, but now you can
say 'let isAllocatable=0' in the register class definition.
TableGen calculates if a register is part of any allocatable register
class, and makes that information available in TargetRegisterDesc::inAllocatableClass.
The goal here is to eliminate use cases for overriding allocation_order_*
methods.
llvm-svn: 132508
|
| |
|
|
|
|
|
|
|
| |
I was confused whether new uint8_t[] would zero-initialize the returned
array, and it seems that so is gcc-4.0.
This should fix the test failures on darwin 9.
llvm-svn: 132500
|
| |
|
|
| |
llvm-svn: 132488
|
| |
|
|
| |
llvm-svn: 132487
|
| |
|
|
|
|
|
|
| |
DBG_VALUEs. This approach has several downsides, for example, it does not work when dbg value is a constant integer, it does not work if reg is defined more than once, it places end of debug value range markers in the wrong place. It even causes misleading incorrect debug info when duplicate DBG_VALUE instructions point to same reg def.
Instead, use simpler approach and let DBG_VALUE follow its predecessor instruction. After live debug value analysis pass, all DBG_VALUE instruction are placed at the right place. Thanks Jakob for the hint!
llvm-svn: 132483
|
| |
|
|
| |
llvm-svn: 132479
|
| |
|
|
|
|
|
| |
This saves two virtual function calls and an Allocatable BitVector test,
making RAFast run 2% faster.
llvm-svn: 132471
|
| |
|
|
|
|
| |
Found by valgrind.
llvm-svn: 132457
|
| |
|
|
| |
llvm-svn: 132456
|
| |
|
|
|
|
| |
No functional change.
llvm-svn: 132455
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
register classes.
It provides information for each register class that cannot be
determined statically, like:
- The number of allocatable registers in a class after filtering out the
reserved and invalid registers.
- The preferred allocation order with registers that overlap callee-saved
registers last.
- The last callee-saved register that overlaps a given physical register.
This information usually doesn't change between functions, so it is
reused for compiling multiple functions when possible. The many
possible combinations of reserved and callee saves registers makes it
unfeasible to compute this information statically in TableGen.
Use RegisterClassInfo to count available registers in various heuristics
in SimpleRegisterCoalescing, making the pass run 4% faster.
llvm-svn: 132450
|
| |
|
|
| |
llvm-svn: 132433
|
| |
|
|
|
|
| |
.debug_loc entries.
llvm-svn: 132427
|
| |
|
|
| |
llvm-svn: 132424
|
| |
|
|
|
|
|
|
| |
types if the vector type is legal.
Fixes rdar://9306086
llvm-svn: 132420
|
| |
|
|
|
|
| |
the TargetLowering enum.
llvm-svn: 132418
|
| |
|
|
|
|
|
| |
This commit caused regressions in i386 flops-[568], matrix, salsa20,
256.bzip2, and enc-md5.
llvm-svn: 132413
|
| |
|
|
|
|
| |
rdar://problem/5660695
llvm-svn: 132411
|
| |
|
|
| |
llvm-svn: 132396
|
| |
|
|
|
|
|
|
|
| |
patch we add a flag to enable a new type legalization decision - to promote
integer elements in vectors. Currently, the rest of the codegen does not support
this kind of legalization. This flag will be removed when the transition is
complete.
llvm-svn: 132394
|
| |
|
|
|
|
|
|
|
|
| |
For targets with no itinerary (x86) it is a nop by default. For
targets with issue width already expressed in the itinerary (ARM) it
bypasses a scoreboard check but otherwise does not affect the
schedule. It does make the code more consistent and complete and
allows new targets to specify their issue width in an arbitrary way.
llvm-svn: 132385
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
turns out that it could cause an infinite loop in some situations. If this code
is triggered and it converts a cleanup into a catchall, but that cleanup was in
already in a cleanup, then the _Unwind_SjLj_Resume could infinite loop. I.e.,
the code doesn't consume the exception object and passes it on to
_Unwind_SjLj_Resume. But _USjLjR expects it to be consumed (since it's landing
at a catchall instead of a cleanup). So it uses the values that are presently
there, which are the values that tell it to jump to the fake landing pad.
<rdar://problem/9508402>
llvm-svn: 132381
|
| |
|
|
|
|
| |
eagerly.
llvm-svn: 132377
|
| |
|
|
| |
llvm-svn: 132373
|
| |
|
|
|
|
| |
debug_pubtypes list.
llvm-svn: 132371
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When assigned ranges are evicted, they are put in the RS_Evicted stage and are
not allowed to evict anything else. That prevents looping automatically.
When evicting ranges just to get a cheaper register, use only spill weights to
find the possible candidates. Avoid breaking hints for this purpose, it is not
worth it.
Start implementing more complex eviction heuristics, guarded by the temporary
-complex-eviction flag. The initial version permits a heavier range to be
evicted if it doesn't have any uses where the evicting range is live. This makes
it a good candidate for live ranfge splitting.
llvm-svn: 132358
|
| |
|
|
| |
llvm-svn: 132309
|
| |
|
|
|
|
|
| |
handler's data area starts with a 4-byte reference to the personality
function, followed by the DWARF LSDA.
llvm-svn: 132302
|
| |
|
|
|
|
|
|
| |
discontinuous through a block."
This commit seems to have broken a darwin 9 tester.
llvm-svn: 132299
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This only affects targets like Mips where branch instructions may kill virtual
registers. Most other targets branch on flag values, so virtual registers are
not involved.
The problem is that MachineBasicBlock::updateTerminator deletes branches and
inserts new ones while LiveVariables keeps a list of pointers to instructions
that kill virtual registers. That list wasn't properly updated in
MBB::SplitCriticalEdge.
llvm-svn: 132298
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
handler.
At this moment, only GCC-style exceptions are supported. Other kinds
of exceptions, including "traditional" SEH and Microsoft Visual C++ exceptions,
need more work--and an compiler exception model that isn't specific to
GCC-style exceptions!
In particular, I imagine that it would be possible to mix "traditional" SEH
with GCC-style EH or Microsoft C++ EH. Currently LLVM has no way (beyond some
target-specific defaults and whole-module compiler switches) of knowing which
scheme to use when.
llvm-svn: 132283
|
| |
|
|
|
|
|
|
|
|
|
| |
LegalizeTypeAction.
This patch does not change the behavior of the type legalizer. The codegen
produces the same code.
This infrastructural change is needed in order to enable complex decisions
for vector types (needed by the vector-select patch).
llvm-svn: 132263
|
| |
|
|
| |
llvm-svn: 132256
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
transformed by the inliner into a branch to the enclosing landing pad
(when inlined through an invoke). If not so optimized, it is lowered
DWARF EH preparation into a call to _Unwind_Resume (or _Unwind_SjLj_Resume
as appropriate). Its chief advantage is that it takes both the
exception value and the selector value as arguments, meaning that there
is zero effort in recovering these; however, the frontend is required
to pass these down, which is not actually particularly difficult.
Also document the behavior of landing pads a bit better, and make it
clearer that it's okay that personality functions don't always land at
landing pads. This is just a fact of life. Don't write optimizations that
rely on pushing things over an unwind edge.
llvm-svn: 132253
|
| |
|
|
| |
llvm-svn: 132250
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Delete the Kill and Def markers in BlockInfo. They are no longer
necessary when BlockInfo describes a continuous live range.
This only affects the relatively rare kind of basic block where a live
range looks like this:
|---x o---|
Now live range splitting can pretend that it is looking at two blocks:
|---x
o---|
This allows the code to be simplified a bit.
llvm-svn: 132245
|
| |
|
|
|
|
|
|
|
|
|
| |
It is important that this function returns the same number of live blocks as
countLiveBlocks(CurLI) because live range splitting uses the number of live
blocks to ensure it is making progress.
This is in preparation of supporting duplicate UseBlock entries for basic blocks
that have a virtual register live-in and live-out, but not live-though.
llvm-svn: 132244
|
| |
|
|
| |
llvm-svn: 132239
|
| |
|
|
|
|
|
|
| |
There was no way to check if a given register/mode pair was valid. We now return
an error code (-2) instead of asserting. If anyone thinks that an assert
at this point is really needed, we can autogen a hasValidDwarfRegNum instead.
llvm-svn: 132236
|
| |
|
|
|
|
|
| |
the Win64 EH mechanism to implement GCC-style exceptions. LLVM supports
hardly anything else at this point!
llvm-svn: 132234
|
| |
|
|
|
|
|
|
|
|
| |
subregisters:
When a value is in a subregister, at least report the location as being
the superregister. We should extend the .td files to encode the bit
range so that we can produce a DW_OP_bit_piece.
llvm-svn: 132224
|
| |
|
|
| |
llvm-svn: 132222
|
| |
|
|
|
|
| |
this. XFAIL'd, because the COFF AsmParser can't handle .section yet.
llvm-svn: 132220
|