summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/RISCV
Commit message (Collapse)AuthorAgeFilesLines
...
* [RISCV] Set isAsCheapAsAMove for ADDI, ORI, XORI, LUIAna Pazos2019-01-243-3/+18
| | | | | | | | | | | | | | | | | Summary: Affected instructions: PseudoLI simplest form (ADDI with X0) ALU operations with immediate (they do not set status flag - ADDI, ORI, XORI) Reviewers: asb Reviewed By: asb Subscribers: shiva0217, rkruppe, kito-cheng, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, zzheng, edward-jones, mgrang, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei Differential Revision: https://reviews.llvm.org/D56526 llvm-svn: 352010
* [RISCV] Set isReMaterializable for ORI, XORIAna Pazos2019-01-241-0/+4
| | | | | | | | | | | | Reviewers: asb Reviewed By: asb Subscribers: asb, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei Differential Revision: https://reviews.llvm.org/D57069 llvm-svn: 352008
* Fixed isReMaterializable setting for LUI instruction.Ana Pazos2019-01-221-1/+2
| | | | llvm-svn: 351895
* Reapply "IR: Add fp operations to atomicrmw"Matt Arsenault2019-01-221-0/+6
| | | | | | | This reapplies commits r351778 and r351782 with RISCV test fixes. llvm-svn: 351850
* [RISCV][NFC] Change naming scheme for RISC-V specific DAG nodesAlex Bradbury2019-01-221-43/+50
| | | | | | | | | | Previously we had names like 'Call' or 'Tail'. This potentially clashes with the naming scheme used elsewhere in RISCVInstrInfo.td. Many other backends would use names like AArch64call or PPCtail. I prefer the SystemZ approach, which uses prefixed all-lowercase names. This matches the naming scheme used for target-independent SelectionDAG nodes. llvm-svn: 351823
* [RISCV] Quick fix for PR40333Alex Bradbury2019-01-221-1/+5
| | | | | | | | | | | | | | Avoid the infinite loop caused by the target DAG combine converting ANYEXT to SIGNEXT and the target-independent DAG combine logic converting back to ANYEXT. Do this by not adding the new node to the worklist. Committing directly as this definitely doesn't make the problem any worse, and I intend to follow-up with a patch that avoids this custom combiner logic altogether and just lowers the i32 operations to a target-specific SelectionDAG node. This should be easier to reason about and improve codegen quality in some cases (though may miss out on some later DAG combines). llvm-svn: 351806
* Revert r351778: IR: Add fp operations to atomicrmwChandler Carruth2019-01-221-6/+0
| | | | | | | | | | | | | This broke the RISCV build, and even with that fixed, one of the RISCV tests behaves surprisingly differently with asserts than without, leaving there no clear test pattern to use. Generally it seems bad for hte IR to differ substantially due to asserts (as in, an alloca is used with asserts that isn't needed without!) and nothing I did simply would fix it so I'm reverting back to green. This also required reverting the RISCV build fix in r351782. llvm-svn: 351796
* [RISCV][NFC] Add break to case statement in RISCVDAGToDAGISel::SelectAlex Bradbury2019-01-221-0/+1
| | | | | | | The break isn't strictly needed yet as there is no subsequent entry in the case. But adding to prevent mistakes further down the road. llvm-svn: 351785
* [RISCV] Fix build after r351778Alex Bradbury2019-01-221-3/+6
| | | | | | | Also add a comment to explain the expansion strategy for atomicrmw {fadd,fsub}. llvm-svn: 351782
* IR: Add fp operations to atomicrmwMatt Arsenault2019-01-221-0/+3
| | | | | | Add just fadd/fsub for now. llvm-svn: 351778
* [RISCV] Add R_RISCV_RELAX relocation to all possible relax candidates.Kito Cheng2019-01-211-7/+15
| | | | | | | | | | | | Summary: Add R_RISCV_RELAX relocation to all possible relax candidates and update corresponding testcase. Reviewers: asb, apazos Differential Revision: https://reviews.llvm.org/D46677 llvm-svn: 351723
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1963-252/+189
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [RISCV] Add codegen support for RV64AAlex Bradbury2019-01-173-48/+230
| | | | | | | | | | | | | | | | | | | | | In order to support codegen RV64A, this patch: * Introduces masked atomics intrinsics for atomicrmw operations and cmpxchg that use the i64 type. These are ultimately lowered to masked operations using lr.w/sc.w, but we need to use these alternate intrinsics for RV64 because i32 is not legal * Modifies RISCVExpandPseudoInsts.cpp to handle PseudoAtomicLoadNand64 and PseudoCmpXchg64 * Modifies the AtomicExpandPass hooks in RISCVTargetLowering to sext/trunc as needed for RV64 and to select the i64 intrinsic IDs when necessary * Adds appropriate patterns to RISCVInstrInfoA.td * Updates test/CodeGen/RISCV/atomic-*.ll to show RV64A support This ends up being a fairly mechanical change, as the logic for RV32A is effectively reused. Differential Revision: https://reviews.llvm.org/D53233 llvm-svn: 351422
* [RISCV] Introduce codegen patterns for RV64M-only instructionsAlex Bradbury2019-01-122-5/+52
| | | | | | | | | | | | | | | | | | As discussed on llvm-dev <http://lists.llvm.org/pipermail/llvm-dev/2018-December/128497.html>, we have to be careful when trying to select the *w RV64M instructions. i32 is not a legal type for RV64 in the RISC-V backend, so operations have been promoted by the time they reach instruction selection. Information about whether the operation was originally a 32-bit operations has been lost, and it's easy to write incorrect patterns. Similarly to the variable 32-bit shifts, a DAG combine on ANY_EXTEND will produce a SIGN_EXTEND if this is likely to result in sdiv/udiv/urem being selected (and so save instructions to sext/zext the input operands). Differential Revision: https://reviews.llvm.org/D53230 llvm-svn: 350993
* [RISCV] Add patterns for RV64I SLLW/SRLW/SRAW instructionsAlex Bradbury2019-01-122-1/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | This restores support for selecting the SLLW/SRLW/SRAW instructions, which was removed in rL348067 as the previous patterns made some unsafe assumptions. Also see the related llvm-dev discussion <http://lists.llvm.org/pipermail/llvm-dev/2018-December/128497.html> Ultimately I didn't introduce a custom SelectionDAG node, but instead added a DAG combine that inserts an AssertZext i5 on the shift amount for an i32 variable-length shift and also added an ANY_EXTEND DAG-combine which will instead produce a SIGN_EXTEND for an i32 variable-length shift, increasing the opportunity to safely select SLLW/SRLW/SRAW. There are obviously different ways of addressing this (a number discussed in the llvm-dev thread), so I'd welcome further feedback and comments. Note that there are now some cases in test/CodeGen/RISCV/rv64i-exhaustive-w-insts.ll where sraw/srlw/sllw is selected even though sra/srl/sll could be used without any extra instructions. Given both are semantically equivalent, there doesn't seem a good reason to prefer one vs the other. Given that would require more logic to still select sra/srl/sll in those cases, I've left it preferring the *w variants. Differential Revision: https://reviews.llvm.org/D56264 llvm-svn: 350992
* [RISCV][MC] Add support for evaluating constant symbols as immediatesAlex Bradbury2019-01-101-8/+1
| | | | | | | | | | | | | | | | | | | | | | | | This further improves compatibility with GNU as, allowing input such as the following to be assembled: .equ CONST, 0x123456 li a0, CONST addi a0, a0, %lo(CONST) .equ CONST, 1 slli a0, a0, CONST Note that we don't have perfect compatibility with gas, as it will avoid emitting a relocation in this case: addi a0, a0, %lo(CONST2) .equ CONST2, 0x123456 Thanks to Shiva Chen for suggesting a better way to approach this during review. Differential Revision: https://reviews.llvm.org/D52298 llvm-svn: 350831
* [RISCV][MC] Accept %lo and %pcrel_lo on operands to liAlex Bradbury2019-01-032-6/+20
| | | | | | This matches GNU assembler behaviour. llvm-svn: 350321
* [RISCV] Properly evaluate fixup_riscv_pcrel_lo12Alex Bradbury2018-12-204-6/+132
| | | | | | | | | | | | | | | | | | | | This is a update to D43157 to correctly handle fixup_riscv_pcrel_lo12. Notable changes: Rebased onto trunk Handle and test S-type Test case pcrel-hilo.s is merged into relocations.s D43157 description: VK_RISCV_PCREL_LO has to be handled specially. The MCExpr inside is actually the location of an auipc instruction with a VK_RISCV_PCREL_HI fixup pointing to the real target. Differential Revision: https://reviews.llvm.org/D54029 Patch by Chih-Mao Chen and Michael Spencer. llvm-svn: 349764
* [RISCV] Add support for the various RISC-V FMA instruction variantsAlex Bradbury2018-12-133-3/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | Adds support for the various RISC-V FMA instructions (fmadd, fmsub, fnmsub, fnmadd). The criteria for choosing whether a fused add or subtract is used, as well as whether the product is negated or not, is whether some of the arguments to the llvm.fma.* intrinsic are negated or not. In the tests, extraneous fadd instructions were added to avoid the negation being performed using a xor trick, which prevented the proper FMA forms from being selected and thus tested. The FMA instruction patterns might seem incorrect (e.g., fnmadd: -rs1 * rs2 - rs3), but they should be correct. The misleading names were inherited from MIPS, where the negation happens after computing the sum. The llvm.fmuladd.* intrinsics still do not generate RISC-V FMA instructions, as that depends on TargetLowering::isFMAFasterthanFMulAndFAdd. Some comments in the test files about what type of instructions are there tested were updated, to better reflect the current content of those test files. Differential Revision: https://reviews.llvm.org/D54205 Patch by Luís Marques. llvm-svn: 349023
* [Targets] Add errors for tiny and kernel codemodel on targets that don't ↵David Green2018-12-071-7/+1
| | | | | | | | | | | support them Adds fatal errors for any target that does not support the Tiny or Kernel codemodels by rejigging the getEffectiveCodeModel calls. Differential Revision: https://reviews.llvm.org/D50141 llvm-svn: 348585
* [RISCV] Remove RV64I SLLW/SRLW/SRAW patterns and add new test casesAlex Bradbury2018-12-011-26/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | As noted by Eli Friedman <https://reviews.llvm.org/D52977?id=168629#1315291>, the RV64I shift patterns for SLLW/SRLW/SRAW make some incorrect assumptions. SRAW assumed that (sext_inreg foo, i32) could only be produced when sign-extended an i32. However, it can be produced by input such as: define i64 @tricky_ashr(i64 %a, i64 %b) { %1 = shl i64 %a, 32 %2 = ashr i64 %1, 32 %3 = ashr i64 %2, %b ret i64 %3 } It's important not to select sraw in the above case, because sraw only uses bits lower 5 bits from the shift, while a shift of 32-63 would be valid. Similarly, the patterns for srlw assumed (and foo, 0xffffffff) would only be produced when zero-extending a value that was originally i32 in LLVM IR. This is obviously incorrect. This patch removes the SLLW/SRLW/SRAW shift patterns for the time being and adds test cases that would demonstrate a miscompile if the incorrect patterns were re-added. llvm-svn: 348067
* [RISCV] Add additional CSR instruction aliases (imm. operands)Alex Bradbury2018-11-301-0/+10
| | | | | | | | | | | | | | This patch adds CSR instructions aliases for the cases where the instruction takes an immediate operand but the alias doesn't have the i suffix. This is necessary for gas/gcc compatibility. gas doesn't do a similar conversion for fsflags or fsrm, so this should be complete. Differential Revision: https://reviews.llvm.org/D55008 Patch by Luís Marques. llvm-svn: 347991
* [RISCV] Add UNIMP instruction (32- and 16-bit forms)Alex Bradbury2018-11-302-0/+17
| | | | | | | | | | | | | | | | | This patch adds support for UNIMP in both 32- and 16-bit forms. The 32-bit form can be seen as a variant of the ECALL/EBREAK/etc. family of instructions. The 16-bit form is just all zeroes, which isn't a valid RISC-V instruction, but still follows the 16-bit instruction form (i.e. bits 0-1 != 11). Until recently unimp was undocumented and supported just by binutils, which printed unimp for either the 16 or 32-bit form. Both forms are now documented <https://github.com/riscv/riscv-asm-manual/pull/20> and binutils now supports c.unimp <https://sourceware.org/ml/binutils-cvs/2018-11/msg00179.html>. Differential Revision: https://reviews.llvm.org/D54316 Patch by Luís Marques. llvm-svn: 347988
* [TargetLowering][RISCV] Introduce isSExtCheaperThanZExt hook and implement ↵Alex Bradbury2018-11-302-0/+5
| | | | | | | | | | | | | | | for RISC-V DAGTypeLegalizer::PromoteSetCCOperands currently prefers to zero-extend operands when it is able to do so. For some targets this is more expensive than a sign-extension, which is also a valid choice. Introduce the isSExtCheaperThanZExt hook and use it in the new SExtOrZExtPromotedInteger helper. On RISC-V, we prefer sign-extension for FromTy == MVT::i32 and ToTy == MVT::i64, as it can be performed using a single instruction. Differential Revision: https://reviews.llvm.org/D52978 llvm-svn: 347977
* [RISCV] Introduce codegen patterns for instructions introduced in RV64IAlex Bradbury2018-11-302-1/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | As discussed in the RFC <http://lists.llvm.org/pipermail/llvm-dev/2018-October/126690.html>, 64-bit RISC-V has i64 as the only legal integer type. This patch introduces patterns to support codegen of the new instructions introduced in RV64I: addiw, addiw, subw, sllw, slliw, srlw, srliw, sraw, sraiw, ld, sd. Custom selection code is needed for srliw as SimplifyDemandedBits will remove lower bits from the mask, meaning the obvious pattern won't work: def : Pat<(sext_inreg (srl (and GPR:$rs1, 0xffffffff), uimm5:$shamt), i32), (SRLIW GPR:$rs1, uimm5:$shamt)>; This is sufficient to compile and execute all of the GCC torture suite for RV64I other than those files using frameaddr or returnaddr intrinsics (LegalizeDAG doesn't know how to promote the operands - a future patch addresses this). When promoting i32 sltu/sltiu operands, it would be more efficient to use sign-extension rather than zero-extension for RV64. A future patch adds a hook to allow this. Differential Revision: https://reviews.llvm.org/D52977 llvm-svn: 347973
* [RISCV] Implement codegen for cmpxchg on RV32IAAlex Bradbury2018-11-294-1/+178
| | | | | | | | | | | | | Utilise a similar ('late') lowering strategy to D47882. The changes to AtomicExpandPass allow this strategy to be utilised by other targets which implement shouldExpandAtomicCmpXchgInIR. All cmpxchg are lowered as 'strong' currently and failure ordering is ignored. This is conservative but correct. Differential Revision: https://reviews.llvm.org/D48131 llvm-svn: 347914
* [RISCV] Support .option push and .option popAlex Bradbury2018-11-285-1/+62
| | | | | | | | | This adds support in the RISCVAsmParser the storing of Subtarget feature bits to a stack so that they can be pushed/popped to enable/disable multiple features at once. Differential Revision: https://reviews.llvm.org/D46424 Patch by Lewis Revill. llvm-svn: 347774
* [RISCV][NFC] Define and use the new CA instruction formatAlex Bradbury2018-11-164-19/+31
| | | | | | | | | | | | The RISC-V ISA manual was updated on 2018-11-07 (commit 00557c3) to define a new compressed instruction format, RVC format CA (no actual instruction encodings were changed). This patch updates the RISC-V backend to define the new format, and to use it in the relevant instructions. Differential Revision: https://reviews.llvm.org/D54302 Patch by Luís Marques. llvm-svn: 347043
* [RISCV] Constant materialisation for RV64IAlex Bradbury2018-11-161-1/+28
| | | | | | | | | | | | | | | | | | | | | | | This commit introduces support for materialising 64-bit constants for RV64I, making use of the RISCVMatInt::generateInstSeq helper in order to share logic for immediate materialisation with the MC layer (where it's used for the li pseudoinstruction). test/CodeGen/RISCV/imm.ll is updated to test RV64, and gains new 64-bit constant tests. It would be preferable if anyext constant returns were sign rather than zero extended (see PR39092). This patch simply adds an explicit signext to the returns in imm.ll. Further optimisations for constant materialisation are possible, most notably for mask-like values which can be generated my loading -1 and shifting right. A future patch will standardise on the C++ codepath for immediate selection on RV32 as well as RV64, and then add further such optimisations to RISCVMatInt::generateInstSeq in order to benefit both RV32 and RV64 for codegen and li expansion. Differential Revision: https://reviews.llvm.org/D52962 llvm-svn: 347042
* [RISCV] Mark C.EBREAK instruction as having side effectsAlex Bradbury2018-11-151-1/+1
| | | | | | | | | | | | | | | C.EBREAK was defined with hasSideEffects = 0, which is incorrect and inconsistent with the non-compressed instruction form. This patch corrects this oversight. This wouldn't cause codegen issues, as compressed instructions are only ever generated by converting the non-compressed form as an MCInst. But having correct flags is still worthwhile. Differential Revision: https://reviews.llvm.org/D54256 Patch by Luís Marques. llvm-svn: 346959
* [RISCV] Mark FREM as ExpandAlex Bradbury2018-11-151-1/+1
| | | | | | | | | | | | Mark the FREM SelectionDAG node as Expand, which is necessary in order to support the frem IR instruction on RISC-V. This is expanded into a library call. Adds the corresponding test. Previously, this would have triggered an assertion at instruction selection time. Differential Revision: https://reviews.llvm.org/D54159 Patch by Luís Marques. llvm-svn: 346958
* [RISCV] Introduce the RISCVMatInt::generateInstSeq helperAlex Bradbury2018-11-154-72/+132
| | | | | | | | | | | | | | | | | | | | | Logic to load 32-bit and 64-bit immediates is currently present in RISCVAsmParser::emitLoadImm in order to support the li pseudoinstruction. With the introduction of RV64 codegen, there is a greater benefit of sharing immediate materialisation logic between the MC layer and codegen. The generateInstSeq helper allows this by producing a vector of simple structs representing the chosen instructions. This can then be consumed in the MC layer to produce MCInsts or at instruction selection time to produce appropriate SelectionDAG node. Sharing this logic means that both the li pseudoinstruction and codegen can benefit from future optimisations, and that this logic can be used for materialising constants during RV64 codegen. This patch does contain a behaviour change: addi will now be produced on RV64 when no lui is necessary to materialise the constant. In that case addiw takes x0 as the source register, so is semantically identical to addi. Differential Revision: https://reviews.llvm.org/D52961 llvm-svn: 346937
* [RISCV] Support .option relax and .option norelaxAlex Bradbury2018-11-127-99/+177
| | | | | | | | | | | | | | | | | | | | | | This extends the .option support from D45864 to enable/disable the relax feature flag from D44886 During parsing of the relax/norelax directives, the RISCV::FeatureRelax feature bits of the SubtargetInfo stored in the AsmParser are updated appropriately to reflect whether relaxation is currently enabled in the parser. When an instruction is parsed, the parser checks if relaxation is currently enabled and if so, gets a handle to the AsmBackend and sets the ForceRelocs flag. The AsmBackend uses a combination of the original RISCV::FeatureRelax feature bits set by e.g -mattr=+/-relax and the ForceRelocs flag to determine whether to emit relocations for symbol and branch diffs. Diff relocations should therefore only not be emitted if the relax flag was not set on the command line and no instruction was ever parsed in a section with relaxation enabled to ensure correct diffs are emitted. Differential Revision: https://reviews.llvm.org/D46423 Patch by Lewis Revill. llvm-svn: 346655
* [RISCV] Avoid unnecessary XOR for seteq/setne 0Alex Bradbury2018-11-091-0/+2
| | | | | | | | Differential Revision: https://reviews.llvm.org/D53492 Patch by James Clarke. llvm-svn: 346497
* [RISCV] Add some missing expansions for floating-point intrinsicsAlex Bradbury2018-11-021-0/+9
| | | | | | | | | | | | | | | | | | A number of intrinsics, such as llvm.sin.f32, would result in a failure to select. This patch adds expansions for the relevant selection DAG nodes, as well as exhaustive testing for all f32 and f64 intrinsics. The codegen for FMA remains a TODO item, pending support for the various RISC-V FMA instruction variants. The llvm.minimum.f32.* and llvm.maximum.* tests are commented-out, pending upstream support for target-independent expansion, as discussed in http://lists.llvm.org/pipermail/llvm-dev/2018-November/127408.html. Differential Revision: https://reviews.llvm.org/D54034 Patch by Luís Marques. llvm-svn: 346034
* [RISCV] Use PatFrags for variable shift patternsAlex Bradbury2018-10-251-10/+9
| | | | | | This follows SystemZ and I think is cleaner vs the multiclass. llvm-svn: 345262
* [RISCV] Eliminate unnecessary masking of promoted shift amountsAlex Bradbury2018-10-121-3/+20
| | | | | | | | | | | | | | | | SelectionDAGBuilder::visitShift will always zero-extend a shift amount when it is promoted to the ShiftAmountTy. This results in zero-extension (masking) which is unnecessary for RISC-V as the shift operations only read the lower 5 or 6 bits (RV32 or RV64). I initially proposed adding a getExtendForShiftAmount hook so the shift amount can be any-extended (D52975). @efriedma explained this was unsafe, so I have instead eliminate the unnecessary and operations at instruction selection time in a manner similar to X86InstrCompiler.td. Differential Revision: https://reviews.llvm.org/D53224 llvm-svn: 344432
* [RISCV] Fix disassembling of fence instruction with invalid fieldAna Pazos2018-10-111-0/+4
| | | | | | | | | | | | | | | | | Summary: Instruction with 0 in fence field being disassembled as fence , iorw. Printing "unknown" to match GAS behavior. This bug was uncovered by a LLVM MC Disassembler Protocol Buffer Fuzzer for the RISC-V assembly language. Reviewers: asb Subscribers: rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, mgrang, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, jfb, PkmX, jocewei, asb Differential Revision: https://reviews.llvm.org/D51828 llvm-svn: 344309
* [RISCV] Compress addiw rd, x0, simm6 to c.li rd, simm6Alex Bradbury2018-10-061-0/+2
| | | | | | | | A pattern was present for addi rd, x0, simm6 but not addiw which is semantically identical when the source register is x0. This patch addresses that, and the benefit can be seen in rv64c-aliases-valid.s. llvm-svn: 343911
* [RISCV] Support named operands for CSR instructions.Ana Pazos2018-10-0417-88/+637
| | | | | | | | | | | | Reviewers: asb, mgrang Reviewed By: asb Subscribers: jocewei, mgorny, jfb, PkmX, MartinMosbeck, brucehoult, the_o, rkruppe, rogfer01, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones Differential Revision: https://reviews.llvm.org/D46759 llvm-svn: 343822
* [RISCV] Remove overzealous is64Bit checksAlex Bradbury2018-10-042-4/+3
| | | | | | | | lowerGlobalAddress, lowerBlockAddress, and insertIndirectBranch contain overzealous checks for is64Bit. These functions are all safe as-implemented for RV64. llvm-svn: 343781
* [RISCV] Bugfix for floats passed on the stack with the ILP32 ABI on RV32FAlex Bradbury2018-10-041-4/+7
| | | | | | | | | | | | | f32 values passed on the stack would previously cause an assertion in unpackFromMemLoc.. This would only trigger in the presence of the F extension making f32 a legal type. Otherwise the f32 would be legalized. This patch fixes that by keeping LocVT=f32 when a float is passed on the stack. It also adds test coverage for this case, and tests that also demonstrate lw/sw/flw/fsw will be selected when most profitable. i.e. there is no unnecessary i32<->f32 conversion in registers. llvm-svn: 343756
* [RISCV][NFC] Fix naming of RISCVISelLowering::{LowerRETURNADDR,LowerFRAMEADDR}Alex Bradbury2018-10-042-7/+7
| | | | | | | Rename to lowerRETURNADDR, lowerFRAMEADDR in order to be consistent with the LLVM coding style and the other functions in this file. llvm-svn: 343752
* [RISCV] Handle redundant SplitF64+BuildPairF64 pairs in a DAGCombineAlex Bradbury2018-10-033-12/+20
| | | | | | | | r343712 performed this optimisation during instruction selection. As Eli Friedman pointed out in post-commit review, implementing this as a DAGCombine might allow opportunities for further optimisations. llvm-svn: 343741
* [RISCV][NFC] Refactor LocVT<->ValVT converstion in RISCVISelLoweringAlex Bradbury2018-10-031-40/+33
| | | | | | | | | | There was some duplicated logic for using the LocInfo of a CCValAssign in order to convert from the ValVT to LocVT or vice versa. Resolve this by factoring out convertLocVTFromValVT from unpackFromRegLoc. Also rename packIntoRegLoc to the more appropriate convertValVTToLocVT and call these helper functions consistently. llvm-svn: 343737
* [RISCV][NFCI] Handle redundant splitf64+buildpairf64 pairs during ↵Alex Bradbury2018-10-031-39/+12
| | | | | | | | | | | | instruction selection Although we can't write a tablegen pattern to remove redundant splitf64+buildf64 pairs due to the multiple return values, we can handle it with some C++ selection code. This is simpler than removing them after instruction selection through RISCVDAGToDAGISel::PostprocessISelDAG, as was done previously. llvm-svn: 343712
* [RISCV][NFC] Refactor RISCVDAGToDAGISel::SelectAlex Bradbury2018-10-031-12/+12
| | | | | | Introduce and use a switch on the opcode. llvm-svn: 343688
* [RISCV] Gate float<->int and double<->int conversion patterns on IsRV32Alex Bradbury2018-10-032-14/+24
| | | | | | | | | The patterns as defined are correct only when XLen==32. This is another preparatory patch for a set of patches that flesh out RV64 codegen. llvm-svn: 343679
* [RISCV] Remove XLenVT==i32 assumptions from RISCVInstrInfo tdAlex Bradbury2018-10-032-11/+11
| | | | | | | | | 1. brcond operates on an condition. 2. atomic_fence and the pseudo AMO instructions should all take xlen immediates This allows the same definitions and patterns to work for RV64 (XLenVT==i64). llvm-svn: 343678
* [RISCV] Gate simm32 materialisation pattern and SW pattern on IsRV32Alex Bradbury2018-10-031-2/+3
| | | | | | These patterns are not correct for RV64. llvm-svn: 343677
OpenPOWER on IntegriCloud