| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
detect an in-eligible block rather than just breaking out of the loop.
llvm-svn: 156166
|
|
|
|
|
|
| |
of the extractor itself.
llvm-svn: 156164
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and expose it as a utility class rather than as free function wrappers.
The simple free-function interface works well for the bugpoint-specific
pass's uses of code extraction, but in an upcoming patch for more
advanced code extraction, they simply don't expose a rich enough
interface. I need to expose various stages of the process of doing the
code extraction and query information to decide whether or not to
actually complete the extraction or give up.
Rather than build up a new predicate model and pass that into these
functions, just take the class that was actually implementing the
functions and lift it up into a proper interface that can be used to
perform code extraction. The interface is cleaned up and re-documented
to work better in a header. It also is now setup to accept the blocks to
be extracted in the constructor rather than in a method.
In passing this essentially reverts my previous commit here exposing
a block-level query for eligibility of extraction. That is no longer
necessary with the more rich interface as clients can query the
extraction object for eligibility directly. This will reduce the number
of walks of the input basic block sequence by quite a bit which is
useful if this enters the normal optimization pipeline.
llvm-svn: 156163
|
|
|
|
|
|
|
|
| |
This moves the logic for selecting a TLS model to a single place,
instead of the previous three (ARM, Mips, and X86 which already
uses this function).
llvm-svn: 156162
|
|
|
|
| |
llvm-svn: 156159
|
|
|
|
| |
llvm-svn: 156158
|
|
|
|
| |
llvm-svn: 156157
|
|
|
|
| |
llvm-svn: 156156
|
|
|
|
|
|
| |
Also combine the code in the 'assert' statement.
llvm-svn: 156155
|
|
|
|
| |
llvm-svn: 156154
|
|
|
|
|
|
| |
This information in now computed by TableGen.
llvm-svn: 156152
|
|
|
|
|
|
|
|
| |
The masks returned by SuperRegClassIterator are computed automatically
by TableGen. This is better than depending on the manually specified
SuperRegClasses.
llvm-svn: 156147
|
|
|
|
|
|
|
| |
The TargetLowering construction needs to use a valid TargetRegisterInfo
instance.
llvm-svn: 156146
|
|
|
|
|
|
|
|
| |
This iterator class provides a more abstract interface to the (Idx,
Mask) lists of super-registers for a register class. The layout of the
tables shouldn't be exposed to clients.
llvm-svn: 156144
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
minor behavior changes with this, but nothing I have seen evidence of in
the wild or expect to be meaningful. The real goal is unifying our logic
and simplifying the interfaces. A summary of the changes follows:
- Make 'callIsSmall' actually accept a callsite so it can handle
intrinsics, and simplify callers appropriately.
- Nuke a completely bogus declaration of 'callIsSmall' that was still
lurking in InlineCost.h... No idea how this got missed.
- Teach the 'isInstructionFree' about the various more intelligent
'free' heuristics that got added to the inline cost analysis during
review and testing. This mostly surrounds int->ptr and ptr->int casts.
- Switch most of the interesting parts of the inline cost analysis that
were essentially computing 'is this instruction free?' to use the code
metrics routine instead. This way we won't keep duplicating logic.
All of this is motivated by the desire to allow other passes to compute
a roughly equivalent 'cost' metric for a particular basic block as the
inline cost analysis. Sadly, re-using the same analysis for both is
really messy because only the actual inline cost analysis is ever going
to go to the contortions required for simplification, SROA analysis,
etc.
llvm-svn: 156140
|
|
|
|
|
|
| |
TargetRegisterClass now gives access to the necessary tables.
llvm-svn: 156122
|
|
|
|
|
|
|
|
|
| |
for the assembler and disassembler. Which were not being set/read correctly
for offsets greater than 22 bits in some cases.
Changes to lib/Target/ARM/ARMAsmBackend.cpp from Gideon Myles!
llvm-svn: 156118
|
|
|
|
|
|
|
|
|
|
|
| |
extraction into a public interface. Also clean it up and apply it more
consistently such that we check for landing pads *anywhere* in the
extracted code, not just in single-block extraction.
This will be used to guide decisions in passes that are planning to
eventually perform a round of code extraction.
llvm-svn: 156114
|
|
|
|
|
|
|
|
| |
being done for malloc)
fix a few typos found by Chad in my previous commit
llvm-svn: 156110
|
|
|
|
|
|
| |
This patch creates and optimizes packets as per Hexagon ISA rules.
llvm-svn: 156109
|
|
|
|
| |
llvm-svn: 156102
|
|
|
|
| |
llvm-svn: 156077
|
|
|
|
|
|
| |
This adds new instructions for Hexagon V4 architecture.
llvm-svn: 156071
|
|
|
|
|
|
|
|
| |
there is no need to fallback to visitCallSite.
This gives a 0.9% in a test case
llvm-svn: 156069
|
|
|
|
|
|
| |
vector elements.
llvm-svn: 156060
|
|
|
|
|
|
| |
lower half correctly. Missed in r155982.
llvm-svn: 156059
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to catch cases like:
%reg1024<def> = MOV r1
%reg1025<def> = MOV r0
%reg1026<def> = ADD %reg1024, %reg1025
r0 = MOV %reg1026
By commuting ADD, it let coalescer eliminate all of the copies. However, there
was a bug in the heuristics where it ended up commuting the ADD in:
%reg1024<def> = MOV r0
%reg1025<def> = MOV 0
%reg1026<def> = ADD %reg1024, %reg1025
r0 = MOV %reg1026
That did no benefit but rather ensure the last MOV would not be coalesced.
rdar://11355268
llvm-svn: 156048
|
|
|
|
|
|
|
|
|
|
| |
The ensures that virtual registers always belong to an allocatable class.
If your target attempts to create a vreg for an operand that has no
allocatable register subclass, you will crash quickly.
This ensures that targets define register classes as intended.
llvm-svn: 156046
|
|
|
|
| |
llvm-svn: 156034
|
|
|
|
|
|
| |
just like it now knows for FMULs.
llvm-svn: 156029
|
|
|
|
|
|
|
| |
and Hybrid for 32 bit, since benchmarks show ILP scheduling is better
most of the time.
llvm-svn: 156028
|
|
|
|
|
|
| |
Lincroft and Medfield.
llvm-svn: 156025
|
|
|
|
| |
llvm-svn: 156023
|
|
|
|
| |
llvm-svn: 156019
|
|
|
|
|
|
| |
be used by clang-tblgen.
llvm-svn: 156000
|
|
|
|
|
|
| |
by providing the latencies for the instructions in X86InstrFPStack.td.
llvm-svn: 155996
|
|
|
|
|
|
|
|
| |
The commit is intended to fix rdar://10961709.
But it is the root cause of PR12720.
Revert it for now.
llvm-svn: 155992
|
|
|
|
| |
llvm-svn: 155986
|
|
|
|
|
|
|
| |
methods. Use a weak value handle to keep up with this.
PR12245
llvm-svn: 155984
|
|
|
|
| |
llvm-svn: 155983
|
|
|
|
|
|
| |
for AsmPrinter.
llvm-svn: 155982
|
|
|
|
|
|
| |
the MachO spec.
llvm-svn: 155976
|
|
|
|
| |
llvm-svn: 155960
|
|
|
|
| |
llvm-svn: 155959
|
|
|
|
| |
llvm-svn: 155957
|
|
|
|
| |
llvm-svn: 155956
|
|
|
|
|
|
| |
PR10799
llvm-svn: 155954
|
|
|
|
| |
llvm-svn: 155947
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Aliases for adding a negative immediate when using an explicit 'w'
suffix. E.g.,
adds.w r2, #-16
adds.w r2, r2, #-16
addw r2, #-16
addw r2, #-16
addw r2, r2, #-16
rdar://11330769
llvm-svn: 155946
|
|
|
|
|
|
|
|
|
|
| |
Expressions for movw/movt don't always have an :upper16: or :lower16:
on them and that's ok. When they don't, it's just a plain [0-65536]
immediate result, effectively the same as a :lower16: variant kind.
rdar://10550147
llvm-svn: 155941
|