| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 281207
|
| |
|
|
|
|
|
|
| |
Unlike SDag, we use a separate G_GEP instruction (much simplified, only taking
a single byte offset) to preserve the pointer type information through
selection.
llvm-svn: 281205
|
| |
|
|
| |
llvm-svn: 281073
|
| |
|
|
| |
llvm-svn: 281069
|
| |
|
|
|
|
|
|
| |
These instructions were only necessary when type information was stored in the
MachineInstr (because only generic MachineInstrs possessed a type). Now that
it's in MachineRegisterInfo, COPY and PHI work fine.
llvm-svn: 281037
|
| |
|
|
| |
llvm-svn: 281036
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want each register to have a canonical type, which means the best place to
store this is in MachineRegisterInfo rather than on every MachineInstr that
happens to use or define that register.
Most changes following from this are pretty simple (you need an MRI anyway if
you're going to be doing any transformations, so just check the type there).
But legalization doesn't really want to check redundant operands (when, for
example, a G_ADD only ever has one type) so I've made use of MCInstrDesc's
operand type field to encode these constraints and limit legalization's work.
As an added bonus, more validation is possible, both in MachineVerifier and
MachineIRBuilder (coming soon).
llvm-svn: 281035
|
| |
|
|
|
|
|
| |
They're another source of generic vregs, which are going to need a type on the
definition when we remove the register width from MachineRegisterInfo.
llvm-svn: 280412
|
| |
|
|
|
|
|
|
|
|
| |
More preparation for dropping source types from MachineInstrs: regsters coming
out of already-selected code (i.e. non-generic instructions) don't have a type,
but that information is needed so we must add it manually.
This is done via a new G_TYPE instruction.
llvm-svn: 280292
|
| |
|
|
|
|
|
|
| |
Legalization ends up creating many G_SEQUENCE/G_EXTRACT pairs which leads to
inefficient codegen (even for -O0), so add a quick pass over the function to
remove them again.
llvm-svn: 280155
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead of putting all possible requests into a single table, we can perform
the extremely dense lookup based on opcode and type-index in constant time
using multi-dimensional array-like things.
This roughly halves the time spent doing legalization, which was dominated by
queries against the Actions table.
llvm-svn: 280011
|
| |
|
|
|
|
| |
std::queue was doing far to many heap allocations to be healthy.
llvm-svn: 279992
|
| |
|
|
| |
llvm-svn: 279988
|
| |
|
|
|
|
|
| |
There should be no functional change here, I'm just making the implementation
of "frem" (to libcall) legalization easier for a followup.
llvm-svn: 279987
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: A follow-up fixing on http://llvm.org/viewvc/llvm-project?view=revision&revision=279905.
Reviewers: bkramer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23985
llvm-svn: 279959
|
| |
|
|
| |
llvm-svn: 279906
|
| |
|
|
| |
llvm-svn: 279905
|
| |
|
|
| |
llvm-svn: 279904
|
| |
|
|
| |
llvm-svn: 279889
|
| |
|
|
|
|
| |
Every pass in the GlobalISel pipeline will need to do something similar.
llvm-svn: 279886
|
| |
|
|
| |
llvm-svn: 279878
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's unclear how the old
%res(32) = G_ICMP { s32, s32 } intpred(eq), %0, %1
is actually different from an s1 verison
%res(1) = G_ICMP { s1, s32 } intpred(eq), %0, %1
so we'll remove it for now.
llvm-svn: 279843
|
| |
|
|
| |
llvm-svn: 279842
|
| |
|
|
| |
llvm-svn: 279841
|
| |
|
|
| |
llvm-svn: 279762
|
| |
|
|
| |
llvm-svn: 279758
|
| |
|
|
|
|
|
|
|
| |
since 2015 (n4387), though it's allowed by a library DR so new implementations
accept it in their C++11 modes...
This should unbreak the build with libstdc++ 4.9.
llvm-svn: 279583
|
| |
|
|
|
|
| |
warnings.
llvm-svn: 279582
|
| |
|
|
|
|
|
| |
They really should have both types represented, but early variants were created
before MachineInstrs could have multiple types so they're rather ambiguous.
llvm-svn: 279567
|
| |
|
|
|
|
|
| |
Next step is doing both legalizations at the same time! Marvel at GlobalISel's
cunning.
llvm-svn: 279566
|
| |
|
|
| |
llvm-svn: 279565
|
| |
|
|
|
|
|
|
| |
Instructions like G_ICMP have multiple types that may need to be legalized (the
boolean output and nearly arbitrary inputs in this case). So the legalizer must
be capable of deciding what to do for each of them separately.
llvm-svn: 279554
|
| |
|
|
|
|
| |
AArch64.
llvm-svn: 279548
|
| |
|
|
| |
llvm-svn: 279341
|
| |
|
|
| |
llvm-svn: 279340
|
| |
|
|
| |
llvm-svn: 279319
|
| |
|
|
| |
llvm-svn: 279311
|
| |
|
|
| |
llvm-svn: 279309
|
| |
|
|
|
|
|
| |
No tests yet unfortunately (ConstantFolding reduces all supported constants to
ConstantInts before we get to translation). Soon.
llvm-svn: 279308
|
| |
|
|
|
|
|
|
|
|
| |
This adds a G_INSERT instruction, which technically makes G_SEQUENCE redundant
(it's equivalent to a G_INSERT into an IMPLICIT_DEF). We'll leave G_SEQUENCE
for now though: it's likely to be far more common as it's a fundamental part of
legalization, so avoiding the mess and bloat of the extra IMPLICIT_DEFs is
probably worthwhile.
llvm-svn: 279306
|
| |
|
|
|
|
|
|
|
|
|
|
| |
First, make sure all types involved are represented, rather than being implicit
from the register width.
Second, canonicalize all types to scalar. These operations just act in bits and
don't care about vectors.
Also standardize spelling of Indices in the MachineIRBuilder (NFC here).
llvm-svn: 279294
|
| |
|
|
| |
llvm-svn: 279287
|
| |
|
|
| |
llvm-svn: 279285
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Unsigned addition and subtraction can reuse the instructions created to
legalize large width operations (i.e. both produce and consume a carry flag).
Signed operations and multiplies get a dedicated op-with-overflow instruction.
Once this is produced the two values are combined into a struct register (which
will almost always be merged with a corresponding G_EXTRACT as part of
legalization).
llvm-svn: 279278
|
| |
|
|
| |
llvm-svn: 278969
|
| |
|
|
| |
llvm-svn: 278810
|
| |
|
|
|
|
| |
And mark it as legal.
llvm-svn: 278802
|
| |
|
|
|
|
|
| |
Before we mischaracterized structs and i1 types as a scalar with size 0 in
various ways.
llvm-svn: 278744
|
| |
|
|
|
|
|
|
| |
It's sharing the integer G_CONSTANT for now since I don't *think* it creates
any ambiguity (even on weird archs). If that turns out wrong we can create a
G_PTRCONSTANT or something.
llvm-svn: 278423
|
| |
|
|
|
|
|
| |
Otherwise we only materialize (shared) constants in the first function they
appear in. This doesn't go well.
llvm-svn: 278351
|