[ARM] GlobalISel: Purge G_SEQUENCE

According to the commit message from r296921, G_MERGE_VALUES and
G_INSERT are to be preferred over G_SEQUENCE. Therefore, stop generating
G_SEQUENCE in the ARM bac

[ARM] GlobalISel: Purge G_SEQUENCE

According to the commit message from r296921, G_MERGE_VALUES and
G_INSERT are to be preferred over G_SEQUENCE. Therefore, stop generating
G_SEQUENCE in the ARM backend and remove the code dealing with it.

This boils down to the code breaking up double values for the soft float
calling convention. Use G_MERGE_VALUES + G_UNMERGE_VALUES instead of
G_SEQUENCE + G_EXTRACT for it. This maps very nicely to VMOVDRR +
VMOVRRD and simplifies the code in the instruction selector.

There's one occurence of G_SEQUENCE left in arm-irtranslator.ll, but
that is part of the target-independent code for translating constant
structs. Therefore, it is beyond the scope of this commit.

llvm-svn: 304902

show more ...

[ARM] GlobalISel: Support G_XOR

Same as the other binary operators:
- legalize to 32 bits
- map to GPRs
- select to EORrr via TableGen'erated code

llvm-svn: 304898

[ARM] GlobalISel: Support G_OR

Same as the other binary operators:
- legalize to 32 bits
- map to GPRs
- select ORRrr thanks to TableGen'erated code

llvm-svn: 304890

[ARM] GlobalISel: Support G_AND

This is identical to the support for the other binary operators:
- widen to s32
- map into GPR
- select ANDrr (via TableGen'erated code)

llvm-svn: 304885

[ARM][GlobalISel] Support for G_ANYEXT

G_ANYEXT can be introduced by the legalizer when widening scalars. Add
support for it in the register bank info (same mapping as everything
else) and in the in

[ARM][GlobalISel] Support for G_ANYEXT

G_ANYEXT can be introduced by the legalizer when widening scalars. Add
support for it in the register bank info (same mapping as everything
else) and in the instruction selector.

When selecting it, we treat it as a COPY, just like G_TRUNC. On this
occasion we get rid of some assertions in selectCopy so we can reuse it.
This shouldn't be a problem at the moment since we're not supporting any
complicated cases (e.g. FPR, different register banks). We might want to
separate the paths when we do.

llvm-svn: 302778

show more ...

[RegisterBankInfo] Uniquely allocate instruction mapping.

This is a step toward having statically allocated instruciton mapping.
We are going to tablegen them eventually, so let us reflect that in
t

[RegisterBankInfo] Uniquely allocate instruction mapping.

This is a step toward having statically allocated instruciton mapping.
We are going to tablegen them eventually, so let us reflect that in
the API.

NFC.

llvm-svn: 302316

show more ...

[ARM] GlobalISel: Support G_(S|U)DIV for s32

Add support for both targets with hardware division and without. For
hardware division we have to add support throughout the pipeline
(legalizer, reg ban

[ARM] GlobalISel: Support G_(S|U)DIV for s32

Add support for both targets with hardware division and without. For
hardware division we have to add support throughout the pipeline
(legalizer, reg bank select, instruction select). For targets without
hardware division, we only need to mark it as a libcall.

llvm-svn: 301164

show more ...

[ARM] GlobalISel: Add support for G_TRUNC

Select them as copies. We only select if both the source and the
destination are on the same register bank, so this shouldn't cause any
trouble.

llvm-svn:

[ARM] GlobalISel: Add support for G_TRUNC

Select them as copies. We only select if both the source and the
destination are on the same register bank, so this shouldn't cause any
trouble.

llvm-svn: 300971

show more ...

[ARM] GlobalISel: Add support for G_MUL

Support G_MUL, very similar to G_ADD and G_SUB. The only difference is
in the instruction selector, where we have to select either MUL or MULv5
depending on t

[ARM] GlobalISel: Add support for G_MUL

Support G_MUL, very similar to G_ADD and G_SUB. The only difference is
in the instruction selector, where we have to select either MUL or MULv5
depending on the target.

llvm-svn: 300665

show more ...

[ARM] GlobalISel: Add support for G_SUB

Support G_SUB throughout the GlobalISel pipeline. It is exactly the same
as G_ADD, nothing fancy.

llvm-svn: 300546

[ARM] GlobalISel: Support SP in regbankselect

We used to hit an unreachable in getRegBankFromRegClass when dealing with the
stack pointer. This commit adds support for the GPRsp reg class.

llvm-svn

[ARM] GlobalISel: Support SP in regbankselect

We used to hit an unreachable in getRegBankFromRegClass when dealing with the
stack pointer. This commit adds support for the GPRsp reg class.

llvm-svn: 297621

show more ...

GlobalISel: restrict G_EXTRACT instruction to just one operand.

A bit more painful than G_INSERT because it was more widely used, but this
should simplify the handling of extract operations in most

GlobalISel: restrict G_EXTRACT instruction to just one operand.

A bit more painful than G_INSERT because it was more widely used, but this
should simplify the handling of extract operations in most locations.

llvm-svn: 297100

show more ...

[ARM] GlobalISel: Add mapping for G_CONSTANT

Like G_FRAME_INDEX, G_CONSTANT has one register operand and one non-register
operand.

llvm-svn: 296469

[ARM] GlobalISel: Add reg bank mapping for G_GEP

This should be the same as the mapping for G_ADD etc.

llvm-svn: 296455

[ARM] GlobalISel: Add reg bank mappings for stores

Same as the ones for loads.

llvm-svn: 296115

[ARM] GlobalISel: Check mappings used by reg bank select

Add some asserts to make sure we're using the mappings that we think we're
using. This is to keep us from accidentally breaking functionality

[ARM] GlobalISel: Check mappings used by reg bank select

Add some asserts to make sure we're using the mappings that we think we're
using. This is to keep us from accidentally breaking functionality while moving
to TableGen'erated mappings.

llvm-svn: 295441

show more ...

[ARM] GlobalISel: Assert that we don't use the FPR bank if we don't have VFP

llvm-svn: 295308

[ARM] GlobalISel: Add reg bank mappings for G_SEQUENCE and G_EXTRACT

Support G_SEQUENCE and G_EXTRACT as needed for passing double precision floating
point values in the soft-fp float mode.

llvm-sv

[ARM] GlobalISel: Add reg bank mappings for G_SEQUENCE and G_EXTRACT

Support G_SEQUENCE and G_EXTRACT as needed for passing double precision floating
point values in the soft-fp float mode.

llvm-svn: 295306

show more ...

[ARM] GlobalISel: Make the FPR bank 64-bit wide

Also add mappings for single and double precision FP, and use them for G_FADD
and G_LOAD.

llvm-svn: 295302

[ARM] GlobalISel: Add FPR reg bank

Add a register bank for floating point values and select simple instructions
using them (add, copies from GPR).

This assumes that the hardware can cope with a sin

[ARM] GlobalISel: Add FPR reg bank

Add a register bank for floating point values and select simple instructions
using them (add, copies from GPR).

This assumes that the hardware can cope with a single precision add (VADDS)
instruction, so the legalizer will treat G_FADD as legal and the instruction
selector will refuse to select if the hardware doesn't support it. In the future
we'll want to be more careful about this, and legalize to libcalls if we have to
use soft float.

llvm-svn: 294442

show more ...

[globalisel][arm] Tablegen-erate current Register Bank Information.

Summary:
This patch tablegen-erates the ARM register bank information so that the
static tables added in D27807 no longer need to

[globalisel][arm] Tablegen-erate current Register Bank Information.

Summary:
This patch tablegen-erates the ARM register bank information so that the
static tables added in D27807 no longer need to be maintained.

Depends on D27338

Reviewers: t.p.northover, rovka, ab, qcolombet, aditya_nandakumar

Reviewed By: rovka

Subscribers: aemerson, rengolin, mgorny, dberris, kristof.beyls, llvm-commits

Differential Revision: https://reviews.llvm.org/D28567

llvm-svn: 294124

show more ...

[ARM] GlobalISel: Support i8/i16 ABI extensions

At the moment, this means supporting the signext/zeroext attribute on the return
type of the function. For function arguments, signext/zeroext should

[ARM] GlobalISel: Support i8/i16 ABI extensions

At the moment, this means supporting the signext/zeroext attribute on the return
type of the function. For function arguments, signext/zeroext should be handled
by the caller, so there's nothing for us to do until we start lowering calls.

Note that this does not include support for other extensions (i8 to i16), those
will be added later.

Differential Revision: https://reviews.llvm.org/D27705

llvm-svn: 293034

show more ...

Re-commit: [globalisel] Tablegen-erate current Register Bank Information

Summary:
Adds a RegisterBank tablegen class that can be used to declare the register
banks and an associated tablegen pass to

Re-commit: [globalisel] Tablegen-erate current Register Bank Information

Summary:
Adds a RegisterBank tablegen class that can be used to declare the register
banks and an associated tablegen pass to generate the necessary code.

Changes since first commit attempt:
* Added missing guards
* Added more missing guards
* Found and fixed a use-after-free bug involving Twine locals

Reviewers: t.p.northover, ab, rovka, qcolombet

Reviewed By: qcolombet

Subscribers: aditya_nandakumar, rengolin, kristof.beyls, vkalintiris, mgorny, dberris, llvm-commits, rovka

Differential Revision: https://reviews.llvm.org/D27338

llvm-svn: 292478

show more ...

Re-revert: [globalisel] Tablegen-erate current Register Bank Information

More missing guards. My build didn't notice it due to a stale file left over
from a Global ISel build.

llvm-svn: 292369

Re-commit: [globalisel] Tablegen-erate current Register Bank Information

Summary:
Adds a RegisterBank tablegen class that can be used to declare the register
banks and an associated tablegen pass to

Re-commit: [globalisel] Tablegen-erate current Register Bank Information

Summary:
Adds a RegisterBank tablegen class that can be used to declare the register
banks and an associated tablegen pass to generate the necessary code.

Changes since last commit:
The new tablegen pass is now correctly guarded by LLVM_BUILD_GLOBAL_ISEL and
this should fix the buildbots however it may not be the whole fix. The previous
buildbot failures suggest there may be a memory bug lurking that I'm unable to
reproduce (including when using asan) or spot in the source. If they re-occur
on this commit then I'll need assistance from the bot owners to track it down.

Reviewers: t.p.northover, ab, rovka, qcolombet

Reviewed By: qcolombet

Subscribers: aditya_nandakumar, rengolin, kristof.beyls, vkalintiris, mgorny, dberris, llvm-commits, rovka

Differential Revision: https://reviews.llvm.org/D27338

llvm-svn: 292367

show more ...