| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
The previous names were both misleading (the MachineLegalizer actually
contained the info tables) and inconsistent with the selector & translator (in
having a "Machine") prefix. This should make everything sensible again.
The only functional change is the name of a couple of command-line options.
llvm-svn: 284287
|
|
|
|
|
|
|
| |
Basically any vector types that fits in a 32-bit register is also valid
as far as copies are concerned.
llvm-svn: 284089
|
|
|
|
|
|
| |
It's going to be a TBNZ (at -O0) anyway, so the high bits don't matter.
llvm-svn: 284070
|
|
|
|
|
|
| |
Those are copies, we do not have to do any legalization action for them.
llvm-svn: 283970
|
|
|
|
|
|
|
| |
Mostly Ahmed's work again, I'm just sprucing things up slightly before
committing.
llvm-svn: 283952
|
|
|
|
|
|
|
| |
Actually every 64-bit loads are legal, but right now the API does not
offer a simple way to express that.
llvm-svn: 283829
|
|
|
|
| |
llvm-svn: 283808
|
|
|
|
| |
llvm-svn: 281602
|
|
|
|
| |
llvm-svn: 281600
|
|
|
|
|
|
|
|
| |
It was only really there as a sentinel when instructions had to have precisely
one type. Now that registers are typed, each register really has to have a type
that is sized.
llvm-svn: 281599
|
|
|
|
|
|
|
| |
Otherwise everything that needs to work out what size they are has to keep a
DataLayout handy, which is a bit silly and very annoying.
llvm-svn: 281597
|
|
|
|
| |
llvm-svn: 281448
|
|
|
|
| |
llvm-svn: 279988
|
|
|
|
| |
llvm-svn: 279845
|
|
|
|
| |
llvm-svn: 279844
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 279840
|
|
|
|
| |
llvm-svn: 279839
|
|
|
|
|
|
| |
It's expected this will map to NZCV register class and be properly selectable.
llvm-svn: 279761
|
|
|
|
|
|
|
|
| |
The 32-bit variants of these operations don't depend on the bits not being
operated on, so they also naturally model operations narrower than the actual
register width.
llvm-svn: 279760
|
|
|
|
| |
llvm-svn: 279759
|
|
|
|
| |
llvm-svn: 279758
|
|
|
|
| |
llvm-svn: 279757
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 279553
|
|
|
|
|
|
| |
AArch64.
llvm-svn: 279548
|
|
|
|
| |
llvm-svn: 279341
|
|
|
|
| |
llvm-svn: 279340
|
|
|
|
|
|
| |
There is no FREM instruction, but the others are straightforward.
llvm-svn: 279081
|
|
|
|
|
|
|
|
| |
There is no REM instruction; that will require an expansion.
It's not obvious that should be done in select, rather than as a
(custom?) legalization.
llvm-svn: 279074
|
|
|
|
|
|
| |
For now, no support for immediates.
llvm-svn: 278804
|
|
|
|
|
|
| |
And mark it as legal.
llvm-svn: 278802
|
|
|
|
|
|
|
| |
These are the operations that are trivially identical. Division is omitted for
now because you need to use the correct sign/zero extension.
llvm-svn: 277775
|
|
|
|
| |
llvm-svn: 277769
|
|
|
|
|
|
|
|
|
|
| |
We currently use and test these, and select most of them. Mark them
as legal even though we don't go through the full ir->asm flow yet.
This doesn't currently have standalone tests, but the verifier will
soon learn to check that the regbankselect/select tests are legal.
llvm-svn: 277471
|
|
This adds the actual MachineLegalizeHelper to do the work and a trivial pass
wrapper that legalizes all instructions in a MachineFunction. Currently the
only transformation supported is splitting up a vector G_ADD into one acting on
smaller vectors.
llvm-svn: 276461
|