| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
This is still a topological ordering such that every register class gets
a smaller enum value than its sub-classes.
Placing the smaller spill sizes first makes a difference for the
super-register class bit masks. When looking for a super-register class,
we usually want the smallest possible kind of super-register. That is
now available as the first bit set in the bit mask.
llvm-svn: 156222
|
|
|
|
|
|
|
|
| |
We want the representative register class to contain the largest
super-registers available. This makes the function less sensitive to the
register class numbering.
llvm-svn: 156220
|
|
|
|
| |
llvm-svn: 156219
|
|
|
|
|
|
|
|
|
| |
This fixes a couple of Clang warnings in release builds of LLVM:
* Missing return in ISelLowering
* Unused variable in NVPTXutil.cpp
llvm-svn: 156216
|
|
|
|
|
|
| |
SignExtend32<22>(Val<<1) also needs to change to SignExtend32<21>(Val) .
llvm-svn: 156213
|
|
|
|
|
|
|
| |
where the symbolic operand's displacement was incorrectly shifted left by 1.
rdar://11387046
llvm-svn: 156212
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In file included from ../lib/Target/NVPTX/VectorElementize.cpp:53:
../lib/Target/NVPTX/NVPTX.h:44:3: warning: default label in switch which covers all enumeration values [-Wcovered-switch-default]
default: assert(0 && "Unknown condition code");
^
1 warning generated.
The prevailing pattern in LLVM is to not use a default label, and instead to
use llvm_unreachable to denote that the switch in fact covers all return paths
from the function.
llvm-svn: 156209
|
|
|
|
|
|
|
| |
RegionInfo's RegionNode. This mirrors the logic for automating the
extraction from a Loop.
llvm-svn: 156208
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
add a new Region::block_iterator which actually iterates over the basic
blocks of the region.
The old iterator, now call 'block_node_iterator' iterates over
RegionNodes which contain a single basic block. This works well with the
GraphTraits-based iterator design, however most users actually want an
iterator over the BasicBlocks inside these RegionNodes. Now the
'block_iterator' is a wrapper which exposes exactly this interface.
Internally it uses the block_node_iterator to walk all nodes which are
single basic blocks, but transparently unwraps the basic block to make
user code simpler.
While this patch is a bit of a wash, most of the updates are to internal
users, not external users of the RegionInfo. I have an accompanying
patch to Polly that is a strict simplification of every user of this
interface, and I'm working on a pass that also wants the same simplified
interface.
This patch alone should have no functional impact.
llvm-svn: 156202
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for NVIDIA PTX 3.0. This back-end will (eventually) replace the current PTX back-end, while maintaining compatibility with it.
The new target machines are:
nvptx (old ptx32) => 32-bit PTX
nvptx64 (old ptx64) => 64-bit PTX
The sources are based on the internal NVIDIA NVPTX back-end, and
contain more functionality than the current PTX back-end currently
provides.
NV_CONTRIB
llvm-svn: 156196
|
|
|
|
|
|
| |
16-bits encoding of CMN instructions.
llvm-svn: 156195
|
|
|
|
| |
llvm-svn: 156194
|
|
|
|
| |
llvm-svn: 156189
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of the CodeExtractor utility. This allows speculatively computing input
and output sets to measure the likely size impact of the code
extraction.
These sets cannot be reused sadly -- we mutate the function prior to
forming the final sets used by the actual extraction.
The interface has been revamped slightly to make it easier to use
correctly by making the interface const and sinking the computation of
the number of exit blocks into the full extraction function and away
from the rest of this logic which just computed two output parameters.
llvm-svn: 156168
|
|
|
|
|
|
|
| |
blocks, assert that this doesn't happen. We don't want to bother trying
to support this call pattern as it isn't necessary.
llvm-svn: 156167
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
This manually enumerated list of super-register classes has been
superceeded by the automatically computed super-register class masks
available through SuperRegClassIterator.
llvm-svn: 156151
|
|
|
|
|
|
| |
using cmake+ninja, since ninja buffers the compiler output.
llvm-svn: 156150
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
but using a FoldingSet underneath and with a largely compatible
interface to that of FoldingSet. This can be used anywhere a FoldingSet
would be natural, but iteration order is significant. The initial
intended use case is in Clang's template specialization lists to
preserve instantiation order iteration.
llvm-svn: 156131
|
|
|
|
|
|
| |
Patch by Meador Inge.
llvm-svn: 156128
|
|
|
|
| |
llvm-svn: 156124
|
|
|
|
|
|
| |
TargetRegisterClass now gives access to the necessary tables.
llvm-svn: 156122
|
|
|
|
|
|
|
|
| |
This is a pointer into one of the tables used by
getMatchingSuperRegClass(). It makes it possible to use a shared
implementation of that function.
llvm-svn: 156121
|
|
|
|
|
|
|
|
|
| |
The RC->getSubClassMask() pointer now points to a sequence of register
class bit masks. The first bit mask is the normal sub-class mask. The
following masks are super-reg class masks used by
getMatchingSuperRegClass().
llvm-svn: 156120
|
|
|
|
|
|
|
|
|
| |
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: 156108
|
|
|
|
| |
llvm-svn: 156102
|
|
|
|
| |
llvm-svn: 156084
|
|
|
|
|
|
|
|
| |
Many register classes only have a few super-registers, so it is not
necessary to keep individual bit masks for all possible sub-register
indices.
llvm-svn: 156083
|
|
|
|
| |
llvm-svn: 156080
|
|
|
|
| |
llvm-svn: 156077
|
|
|
|
|
|
|
|
| |
Some targets have no sub-registers at all. Use the TargetRegisterInfo
versions of composeSubRegIndices(), getSubClassWithSubReg(), and
getMatchingSuperRegClass() for those targets.
llvm-svn: 156075
|
|
|
|
|
|
| |
This adds new instructions for Hexagon V4 architecture.
llvm-svn: 156071
|