summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/GlobalISel/MachineIRBuilder.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [MachineIRBuilder] Fix formatting. NFC.Diana Picus2017-07-051-1/+1
| | | | llvm-svn: 307144
* [MachineIRBuilder] Add buildOr helper. NFC.Diana Picus2017-07-051-0/+4
| | | | | | This isn't used anywhere yet, but I need it for a future commit. llvm-svn: 307141
* [MachineIRBuilder] Add buildBinaryOp helper. NFCDiana Picus2017-07-051-29/+11
| | | | | | | Add a helper for building simple binary ops like add, mul, sub, and. This can be used in the future for quickly adding support for or, xor. llvm-svn: 307139
* GlobalISel: add G_IMPLICIT_DEF instruction.Tim Northover2017-06-301-1/+1
| | | | | | | | | It looks like there are two target-independent but not GISel instructions that need legalization, IMPLICIT_DEF and PHI. These are already anomalies since their operands have important LLTs attached, so to make things more uniform it seems like a good idea to add generic variants. Starting with G_IMPLICIT_DEF. llvm-svn: 306875
* GlobalISel: add some more sanity-checking to MachineInstrBuilder. NFC.Tim Northover2017-06-271-1/+15
| | | | llvm-svn: 306481
* GlobalISel: verify that a COPY is trivial when created.Tim Northover2017-06-271-2/+3
| | | | | | | | | | | | Without this check, COPY instructions can actually be one of the generic casts in disguise. That's confusing and bad. At some point during ISel this restriction has to be relaxed since the fully selected instructions will usually use COPY for those purposes. Right now I think it's possible that relaxation occurs during RegBankSelect (hence the change there). I'm not convinced that's where it belongs long-term though. llvm-svn: 306470
* AArch64: legalize G_EXTRACT operations.Tim Northover2017-06-261-0/+3
| | | | | | | This is the dual problem to legalizing G_INSERTs so most of the code and testing was cribbed from there. llvm-svn: 306328
* GlobalISel: convert buildSequence to use non-deprecated instructions.Tim Northover2017-06-231-9/+25
| | | | | | | | G_SEQUENCE is going away soon so as a first step the MachineIRBuilder needs to be taught how to emulate it with alternatives. We use G_MERGE_VALUES where possible, and a sequence of G_INSERTs if not. llvm-svn: 306119
* [globalisel][legalizer] G_LOAD/G_STORE NarrowScalar should not emit G_GEP x, 0.Daniel Sanders2017-06-131-0/+18
| | | | | | | | | | | | | | | | | | | Summary: When legalizing G_LOAD/G_STORE using NarrowScalar, we should avoid emitting %0 = G_CONSTANT ty 0 %1 = G_GEP %x, %0 since it's cheaper to not emit the redundant instructions than it is to fold them away later. Reviewers: qcolombet, t.p.northover, ab, rovka, aditya_nandakumar, kristof.beyls Reviewed By: qcolombet Subscribers: javed.absar, llvm-commits, igorb Differential Revision: https://reviews.llvm.org/D32746 llvm-svn: 305340
* [GlobalISel] Support vector-of-pointers in LLTKristof Beyls2017-04-191-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes PR32471. As comment 10 on that bug report highlights (https://bugs.llvm.org//show_bug.cgi?id=32471#c10), there are quite a few different defendable design tradeoffs that could be made, including not representing pointers at all in LLT. I decided to go for representing vector-of-pointer as a concept in LLT, while keeping the size of the LLT type 64 bits (this is an increase from 48 bits before). My rationale for keeping pointers explicit is that on some targets probably it's very handy to have the distinction between pointer and non-pointer (e.g. 68K has a different register bank for pointers IIRC). If we keep a scalar pointer, it probably is easiest to also have a vector-of-pointers to keep LLT relatively conceptually clean and orthogonal, while we don't have a very strong reason to break that orthogonality. Once we gain more experience on the use of LLT, we can of course reconsider this direction. Rejecting vector-of-pointer types in the IRTranslator is also an option to avoid the crash reported in PR32471, but that is only a very short-term solution; also needs quite a bit of code tweaks in places, and is probably fragile. Therefore I didn't consider this the best option. llvm-svn: 300664
* Revert "[GlobalISel] Support vector-of-pointers in LLT"Kristof Beyls2017-04-181-3/+2
| | | | | | | | | | | | | | | | This reverts r300535 and r300537. The newly added tests in test/CodeGen/AArch64/GlobalISel/arm64-fallback.ll produces slightly different code between LLVM versions being built with different compilers. E.g., dependent on the compiler LLVM is built with, either one of the following can be produced: remark: <unknown>:0:0: unable to legalize instruction: %vreg0<def>(p0) = G_EXTRACT_VECTOR_ELT %vreg1, %vreg2; (in function: vector_of_pointers_extractelement) remark: <unknown>:0:0: unable to legalize instruction: %vreg2<def>(p0) = G_EXTRACT_VECTOR_ELT %vreg1, %vreg0; (in function: vector_of_pointers_extractelement) Non-determinism like this is clearly a bad thing, so reverting this until I can find and fix the root cause of the non-determinism. llvm-svn: 300538
* [GlobalISel] Support vector-of-pointers in LLTKristof Beyls2017-04-181-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes PR32471. As comment 10 on that bug report highlights (https://bugs.llvm.org//show_bug.cgi?id=32471#c10), there are quite a few different defendable design tradeoffs that could be made, including not representing pointers at all in LLT. I decided to go for representing vector-of-pointer as a concept in LLT, while keeping the size of the LLT type 64 bits (this is an increase from 48 bits before). My rationale for keeping pointers explicit is that on some targets probably it's very handy to have the distinction between pointer and non-pointer (e.g. 68K has a different register bank for pointers IIRC). If we keep a scalar pointer, it probably is easiest to also have a vector-of-pointers to keep LLT relatively conceptually clean and orthogonal, while we don't have a very strong reason to break that orthogonality. Once we gain more experience on the use of LLT, we can of course reconsider this direction. Rejecting vector-of-pointer types in the IRTranslator is also an option to avoid the crash reported in PR32471, but that is only a very short-term solution; also needs quite a bit of code tweaks in places, and is probably fragile. Therefore I didn't consider this the best option. llvm-svn: 300535
* [GlobalISel] Translate insertelement and extractelementVolkan Keles2017-03-101-0/+40
| | | | | | | | | | | | Reviewers: qcolombet, aditya_nandakumar, dsanders, ab, t.p.northover, javed.absar Reviewed By: qcolombet Subscribers: dberris, rovka, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D30761 llvm-svn: 297495
* [GlobalISel] Relax vector G_SELECT assertion.Ahmed Bougacha2017-03-071-3/+4
| | | | | | | | | | | For vector operands, the `select` instruction supports both vector and non-vector conditions. The MIR builder had an overly restrictive assertion, that only accepted vector conditions for vector selects (in effect implementing ISD::VSELECT). Make it possible to express the full range of G_SELECTs. llvm-svn: 297207
* [GlobalISel] Slightly clean up DBG_VALUE FP build code.Ahmed Bougacha2017-03-071-2/+1
| | | | | | | I messed up my rebases leading to r297200, and ended up with stale (but working) code. Fix it. llvm-svn: 297205
* [GlobalISel] Emit DBG_VALUE %noreg for non-int/fp constant values.Ahmed Bougacha2017-03-071-1/+6
| | | | | | | | When a dbg_value has a constant operand that isn't representable in MI, there isn't much we can do. Use %noreg (0) for those situations. This matches the SelectionDAG behavior. llvm-svn: 297200
* GlobalISel: restrict G_EXTRACT instruction to just one operand.Tim Northover2017-03-061-23/+14
| | | | | | | 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
* GlobalISel: don't emit degenerate G_INSERT instructions.Tim Northover2017-03-061-0/+25
| | | | | | | | | | | Before, we were producing G_INSERT instructions that were actually closer to a cast or even a COPY when both input and output sizes are the same. This doesn't really make sense and means that everything interpreting a G_INSERT also has to handle all these kinds of casts. So now we detect these degenerate cases and emit real casts instead. llvm-svn: 297051
* GlobalISel: add buildUndef method to MachineIRBuilder. NFC.Tim Northover2017-03-061-0/+4
| | | | llvm-svn: 297044
* GlobalISel: constrain G_INSERT to inserting just one value per instruction.Tim Northover2017-03-031-0/+9
| | | | | | | It's much easier to reason about single-value inserts and no-one was actually using the variadic variants before. llvm-svn: 296923
* GlobalISel: add merge/unmerge nodes for legalization.Tim Northover2017-03-031-0/+40
| | | | | | | | | | | | | | These are simplified variants of the current G_SEQUENCE and G_EXTRACT, which assume the individual parts will be contiguous, homogeneous, and occupy the entirity of the larger register. This makes reasoning about them much easer since you only have to look at the first register being merged and the result to know what the instruction is doing. I intend to gradually replace all uses of the more complicated sequence/extract with these (or single-element insert/extracts), and then remove the older variants. For now we start with legalization. llvm-svn: 296921
* GlobalISel: introduce G_PTR_MASK to simplify alloca handling.Tim Northover2017-02-141-0/+11
| | | | | | | | | This instruction clears the low bits of a pointer without requiring (possibly dodgy if pointers aren't ints) conversions to and from an integer. Since (as far as I'm aware) all masks are statically known, the instruction takes an immediate operand rather than a register to specify the mask. llvm-svn: 295103
* GlobalISel: translate dynamic alloca instructions.Tim Northover2017-02-031-0/+24
| | | | llvm-svn: 294022
* [GlobalISel] Add support for indirectbrKristof Beyls2017-01-301-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D28079 llvm-svn: 293470
* GlobalISel: support debug intrinsics.Tim Northover2017-01-261-0/+61
| | | | | | | | The translation scheme is mostly cribbed from FastISel, and it's not entirely convincing semantically. But it does seem to work in the common cases and allow variables to be printed so it can't be all wrong. llvm-svn: 293228
* Apply clang-tidy's performance-unnecessary-value-param to LLVM.Benjamin Kramer2017-01-131-1/+1
| | | | | | | With some minor manual fixes for using function_ref instead of std::function. No functional change intended. llvm-svn: 291904
* GlobalISel: simplify MachineIRBuilder interface.Tim Northover2016-12-071-16/+11
| | | | | | | | | | | | MachineIRBuilder had weird before/after and beginning/end flags for the insert point. Unfortunately the non-default means that instructions will be inserted in reverse order which is almost never what anyone wants. Really, I think we just want (like IRBuilder has) the ability to insert at any C++ iterator-style point (i.e. before any instruction or before MBB.end()). So this fixes MIRBuilders to behave like IRBuilders in this respect. llvm-svn: 288980
* GlobalISel: allow G_SELECT instructions for pointers.Tim Northover2016-12-061-4/+5
| | | | llvm-svn: 288835
* Add missing parens in assert.Sam McCall2016-12-061-1/+1
| | | | | | | | | | Summary: Add missing parens in assert, which warn in GCC. Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D27448 llvm-svn: 288792
* GlobalISel: make G_CONSTANT take a ConstantInt rather than int64_t.Tim Northover2016-12-051-3/+19
| | | | | | | | This makes it more similar to the floating-point constant, and also allows for larger constants to be translated later. There's no real functional change in this patch though, just syntax updates. llvm-svn: 288712
* GlobalISel: handle stack-based parameters on AArch64.Tim Northover2016-09-221-0/+9
| | | | llvm-svn: 282153
* GlobalISel: split aggregates for PCS loweringTim Northover2016-09-201-1/+2
| | | | | | | | | | | This should match the existing behaviour for passing complicated struct and array types, in particular HFAs come through like that from Clang. For C & C++ we still need to somehow support all the weird ABI flags, or at least those that are present in the IR (signext, byval, ...), and stack-based parameter passing. llvm-svn: 281977
* GlobalISel: relax type constraints on G_ICMP to allow pointers.Tim Northover2016-09-151-3/+1
| | | | llvm-svn: 281600
* GlobalISel: support translation of global addresses.Tim Northover2016-09-121-0/+12
| | | | llvm-svn: 281207
* GlobalISel: translate GEP instructions.Tim Northover2016-09-121-0/+23
| | | | | | | | 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
* GlobalISel: fix comments and add assertions for valid instructions.Tim Northover2016-09-091-4/+88
| | | | llvm-svn: 281036
* GlobalISel: move type information to MachineRegisterInfo.Tim Northover2016-09-091-99/+68
| | | | | | | | | | | | | | | | | 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
* GlobalISel: use G_TYPE to annotate physregs with a type.Tim Northover2016-08-311-0/+5
| | | | | | | | | | 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
* GlobalISel: combine extracts & sequences created for legalizationTim Northover2016-08-301-0/+4
| | | | | | | | 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
* GlobalISel: legalize sdiv and srem operations.Tim Northover2016-08-261-0/+16
| | | | llvm-svn: 279842
* GlobalISel: add missing type to G_UADDE instructionsTim Northover2016-08-251-5/+4
| | | | llvm-svn: 279762
* GlobalISel: perform multi-step legalizationTim Northover2016-08-251-0/+14
| | | | llvm-svn: 279758
* #ifdef out validation code when asserts are disabled to remove unused variableRichard Smith2016-08-231-0/+2
| | | | | | warnings. llvm-svn: 279582
* GlobalISel: make truncate/extend casts uniformTim Northover2016-08-231-9/+33
| | | | | | | 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
* GlobalISel: legalize integer comparisons on AArch64.Tim Northover2016-08-231-0/+10
| | | | | | | Next step is doing both legalizations at the same time! Marvel at GlobalISel's cunning. llvm-svn: 279566
* GlobalISel: support legalization of G_FCONSTANTsTim Northover2016-08-191-0/+5
| | | | llvm-svn: 279341
* GlobalISel: translate floating-point comparisonsTim Northover2016-08-191-0/+11
| | | | llvm-svn: 279319
* GlobalISel: translate floating-point constantsTim Northover2016-08-191-0/+5
| | | | llvm-svn: 279311
* GlobalISel: support translating select instructions.Tim Northover2016-08-191-0/+10
| | | | llvm-svn: 279309
* GlobalISel: improve representation of G_SEQUENCE and G_EXTRACTTim Northover2016-08-191-11/+26
| | | | | | | | | | | | 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
OpenPOWER on IntegriCloud