summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/Hexagon/HexagonISelLowering.h
Commit message (Collapse)AuthorAgeFilesLines
* CodeGen: Use LLT instead of EVT in getRegisterByNameMatt Arsenault2020-01-091-1/+1
| | | | | | Only PPC seems to be using it, and only checks some simple cases and doesn't distinguish between FP. Just switch to using LLT to simplify use from GlobalISel.
* DAG: Add function context to isFMAFasterThanFMulAndFAddMatt Arsenault2019-11-191-1/+2
| | | | | | | | AMDGPU needs to know the FP mode for the function to answer this correctly when this is removed from the subtarget. AArch64 had to make this more complicated by using this from an IR hook, so add an IR typed overload.
* TLI: Remove DAG argument from getRegisterByNameMatt Arsenault2019-10-011-2/+2
| | | | | | | | | | | Replace with the MachineFunction. X86 is the only user, and only uses it for the function. This removes one obstacle from using this in GlobalISel. The other is the more tolerable EVT argument. The X86 use of the function seems questionable to me. It checks hasFP, before frame lowering. llvm-svn: 373292
* [Hexagon] Generate min/max instructions for 64-bit vectorsKrzysztof Parzyszek2019-08-161-0/+2
| | | | llvm-svn: 369124
* [Hexagon] Generate vector min/max for HVXKrzysztof Parzyszek2019-08-151-1/+6
| | | | llvm-svn: 369014
* [Codegen] (X & (C l>>/<< Y)) ==/!= 0 --> ((X <</l>> Y) & C) ==/!= 0 foldRoman Lebedev2019-07-241-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This was originally reported in D62818. https://rise4fun.com/Alive/oPH InstCombine does the opposite fold, in hope that `C l>>/<< Y` expression will be hoisted out of a loop if `Y` is invariant and `X` is not. But as it is seen from the diffs here, if it didn't get hoisted, the produced assembly is almost universally worse. Much like with my recent "hoist add/sub by/from const" patches, we should get almost universal win if we hoist constant, there is almost always an "and/test by imm" instruction, but "shift of imm" not so much, so we may avoid having to materialize the immediate, and thus need one less register. And since we now shift not by constant, but by something else, the live-range of that something else may reduce. Special care needs to be applied not to disturb x86 `BT` / hexagon `tstbit` instruction pattern. And to not get into endless combine loop. Reviewers: RKSimon, efriedma, t.p.northover, craig.topper, spatel, arsenm Reviewed By: spatel Subscribers: hiraditya, MaskRay, wuzish, xbolva00, nikic, nemanjai, jvesely, wdng, nhaehnle, javed.absar, tpr, kristof.beyls, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62871 llvm-svn: 366955
* [Hexagon] Custom-lower UADDO(x, 1) and USUBO(x, 1)Krzysztof Parzyszek2019-07-011-0/+1
| | | | llvm-svn: 364790
* [TargetLowering] Add MachineMemOperand::Flags to allowsMemoryAccess tests ↵Simon Pilgrim2019-06-121-1/+1
| | | | | | | | | | | | | | (PR42123) As discussed on D62910, we need to check whether particular types of memory access are allowed, not just their alignment/address-space. This NFC patch adds a MachineMemOperand::Flags argument to allowsMemoryAccess and allowsMisalignedMemoryAccesses, and wires up calls to pass the relevant flags to them. If people are happy with this approach I can then update X86TargetLowering::allowsMisalignedMemoryAccesses to handle misaligned NT load/stores. Differential Revision: https://reviews.llvm.org/D63075 llvm-svn: 363179
* [TargetLowering] Change getOptimalMemOpType to take a function attribute listSjoerd Meijer2019-04-301-1/+1
| | | | | | | | | | | | The MachineFunction wasn't used in getOptimalMemOpType, but more importantly, this allows reuse of findOptimalMemOpLowering that is calling getOptimalMemOpType. This is the groundwork for the changes in D59766 and D59787, that allows implementation of TTI::getMemcpyCost. Differential Revision: https://reviews.llvm.org/D59785 llvm-svn: 359537
* [TargetLowering] Add code size information on isFPImmLegal. NFCAdhemerval Zanella2019-03-181-1/+2
| | | | | | | | | | | This allows better code size for aarch64 floating point materialization in a future patch. Reviewers: evandro Differential Revision: https://reviews.llvm.org/D58690 llvm-svn: 356389
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* [TargetLowering] Change TargetLoweringBase::getPreferredVectorAction to take ↵Craig Topper2018-11-051-1/+1
| | | | | | | | an MVT instead of an EVT. NFC The main caller of this already has an MVT and several targets called getSimpleVT inside without checking isSimple. This makes the simpleness explicit. llvm-svn: 346180
* [Hexagon] Do not reduce load size for globals in small-dataKrzysztof Parzyszek2018-11-021-0/+3
| | | | | | | | | | | | Small-data (i.e. GP-relative) loads and stores allow 16-bit scaled offset. For a load of a value of type T, the small-data area is equivalent to an array "T sdata[65536]". This implies that objects of smaller sizes need to be closer to the beginning of sdata, while larger objects may be farther away, or otherwise the offset may be insufficient to reach it. Similarly, an object of a larger size should not be accessed via a load of a smaller size. llvm-svn: 345975
* [AtomicExpandPass]: Add a hook for custom cmpxchg expansion in IRAlex Bradbury2018-09-191-1/+2
| | | | | | | | | | | | | | | | | This involves changing the shouldExpandAtomicCmpXchgInIR interface, but I have updated the in-tree backends using this hook (ARM, AArch64, Hexagon) so they will see no functional change. Previously this hook returned bool, but it now returns AtomicExpansionKind. This hook allows targets to select how a given cmpxchg is to be expanded. D48131 uses this to expand part-word cmpxchg to a target-specific intrinsic. See my associated RFC for more info on the motivation for this change <http://lists.llvm.org/pipermail/llvm-dev/2018-June/123993.html>. Differential Revision: https://reviews.llvm.org/D48130 llvm-svn: 342550
* Add support for getRegisterByName.Sid Manning2018-09-071-0/+3
| | | | | | | | Support required to build the Hexagon Linux kernel. Differential Revision: https://reviews.llvm.org/D51363 llvm-svn: 341658
* Revert [Hexagon] Add support for getRegisterByName.Sid Manning2018-09-031-3/+0
| | | | | | Support required to build the Hexagon Linux kernel. llvm-svn: 341331
* [Hexagon] Add support for getRegisterByName.Sid Manning2018-08-311-0/+3
| | | | | | | | Support required to build the Hexagon Linux kernel. Differential Revision: https://reviews.llvm.org/D51363 llvm-svn: 341238
* [Hexagon] Diagnose misaligned absolute loads and storesKrzysztof Parzyszek2018-08-081-1/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D50405 llvm-svn: 339272
* [SelectionDAG] Provide default expansion for rotatesKrzysztof Parzyszek2018-06-121-0/+1
| | | | | | | | | | | | | Implement default legalization of rotates: either in terms of the rotation in the opposite direction (if legal), or in terms of shifts and ors. Implement generating of rotate instructions for Hexagon. Hexagon only supports rotates by an immediate value, so implement custom lowering of ROTL/ROTR on Hexagon. If a rotate is not legal, use the default expansion. Differential Revision: https://reviews.llvm.org/D47725 llvm-svn: 334497
* [Hexagon] Select HVX code for vector CTPOP, CTLZ, and CTTZKrzysztof Parzyszek2018-06-011-0/+1
| | | | llvm-svn: 333760
* [SelectionDAG] Expand UADDO/USUBO into ADD/SUBCARRY if legal for targetKrzysztof Parzyszek2018-06-011-0/+3
| | | | | | | | | Additionally, implement handling of ADD/SUBCARRY on Hexagon, utilizing the UADDO/USUBO expansion. Differential Revision: https://reviews.llvm.org/D47559 llvm-svn: 333751
* [Hexagon] Improve HVX instruction selection (bitcast, vsplat)Krzysztof Parzyszek2018-04-201-1/+3
| | | | | | | | | | There was some unfortunate interaction between VSPLAT and BITCAST related to the selection of constant vectors (coming from selecting shuffles). Introduce VSPLATW that always splats a 32-bit word, and can have arbitrary result type (to avoid BITCASTs of VSPLAT). Clean up the previous selection of BITCAST/VSPLAT. llvm-svn: 330471
* [IR][CodeGen] Remove dependency on EVT from IR/Function.cpp. Move EVT to ↵Craig Topper2018-03-291-1/+1
| | | | | | | | | | | | CodeGen layer. Currently EVT is in the IR layer only because of Function.cpp needing a very small piece of the functionality of EVT::getEVTString(). The rest of EVT is used in codegen making CodeGen a better place for it. The previous code converted a Type* to EVT and then called getEVTString. This was only expected to handle the primitive types from Type*. Since there only a few primitive types, we can just print them as strings directly. Differential Revision: https://reviews.llvm.org/D45017 llvm-svn: 328806
* Fix layering by moving ValueTypes.h from CodeGen to IRDavid Blaikie2018-03-231-1/+1
| | | | | | ValueTypes.h is implemented in IR already. llvm-svn: 328397
* Fix layering of MachineValueType.h by moving it from CodeGen to SupportDavid Blaikie2018-03-231-1/+1
| | | | | | | | | This is used by llvm tblgen as well as by LLVM Targets, so the only common place is Support for now. (maybe we need another target for these sorts of things - but for now I'm at least making them correct & we can make them better if/when people have strong feelings) llvm-svn: 328395
* [Hexagon] Counting leading/trailing bits is cheapKrzysztof Parzyszek2018-03-121-0/+4
| | | | llvm-svn: 327308
* [Hexagon] Rewrite non-HVX unaligned loads as pairs of aligned onesKrzysztof Parzyszek2018-03-071-2/+4
| | | | | | | | | This is a follow-up to r325169, this time for all types, not just HVX vector types. Disable this by default, since it's not always safe. llvm-svn: 326915
* [Hexagon] Split HVX vector pair loads/stores, expand unaligned loadsKrzysztof Parzyszek2018-02-141-0/+5
| | | | llvm-svn: 325169
* [Hexagon] Extract HVX lowering and selection into HVX-specific files, NFCKrzysztof Parzyszek2018-02-061-0/+7
| | | | llvm-svn: 324392
* [Hexagon] Split HVX operations on vector pairsKrzysztof Parzyszek2018-02-061-0/+6
| | | | | | | | Vector pairs are legal types, but not every operation can work on pairs. For those operations that are legal for single vectors, generate a concat of their results on pair halves. llvm-svn: 324350
* [Hexagon] Add helper functions to identify single/pair vector types, NFCKrzysztof Parzyszek2018-02-061-0/+2
| | | | llvm-svn: 324349
* [Hexagon] Handle lowering of SETCC via setCondCodeActionKrzysztof Parzyszek2018-02-061-0/+2
| | | | | | | | | | It was expanded directly into instructions earlier. That was to avoid loads from a constant pool for a vector negation: "xor x, splat(i1 -1)". Implement ISD opcodes QTRUE and QFALSE to denote logical vectors of all true and all false values, and handle setcc with negations through selection patterns. llvm-svn: 324348
* [Hexagon] Rename HexagonISelLowering::getNode to getInstr, NFCKrzysztof Parzyszek2018-01-311-2/+2
| | | | llvm-svn: 323916
* [Hexagon] Implement HVX codegen for vector shiftsKrzysztof Parzyszek2018-01-311-0/+1
| | | | llvm-svn: 323914
* [Hexagon] Remove unused HexagonISD opcodes, NFCKrzysztof Parzyszek2018-01-241-3/+0
| | | | llvm-svn: 323324
* [Hexagon] Implement basic vector operations on vectors vNi1Krzysztof Parzyszek2018-01-231-6/+48
| | | | | | | | | | | In addition to that, make sure that there are no boolean vector types that are associated with multiple register classes. Specifically, remove v32i1 and v64i1 from integer register classes. These types will correspond to results of vector comparisons, and as such should belong to the vector predicate class. Having them in scalar registers as well makes legalization ambiguous. llvm-svn: 323229
* [Hexagon] Implement signed and unsigned multiply-high for vectorsKrzysztof Parzyszek2018-01-151-0/+1
| | | | llvm-svn: 322499
* [Hexagon] Replace INSERTRP/EXTRACTRP with INSERT/EXTRACT in HexagonISDKrzysztof Parzyszek2018-01-041-2/+0
| | | | llvm-svn: 321798
* [Hexagon] Allow construction of HVX vector predicatesKrzysztof Parzyszek2017-12-201-0/+12
| | | | | | Handle BUILD_VECTOR of boolean values. llvm-svn: 321220
* [Hexagon] Generate HVX code for vector sign-, zero- and any-extendsKrzysztof Parzyszek2017-12-181-0/+1
| | | | | | Implement any-extend as zero-extend. llvm-svn: 321004
* [Hexagon] Prefer to widen HVX vectors instead of promotingKrzysztof Parzyszek2017-12-181-0/+2
| | | | llvm-svn: 321002
* TLI: Allow using PSV for intrinsic mem operandsMatt Arsenault2017-12-141-0/+1
| | | | llvm-svn: 320756
* [Hexagon] Generate HVX code for comparisons and selectsKrzysztof Parzyszek2017-12-141-0/+1
| | | | llvm-svn: 320744
* [Hexagon] Add support for Hexagon V65Krzysztof Parzyszek2017-12-111-0/+3
| | | | llvm-svn: 320404
* [Hexagon] Generate HVX code for basic arithmetic operationsKrzysztof Parzyszek2017-12-071-25/+26
| | | | | | Handle and, or, xor, add, sub, mul for vectors of i8, i16, and i32. llvm-svn: 320063
* [Hexagon] Generate HVX code for vector construction and accessKrzysztof Parzyszek2017-12-061-2/+55
| | | | | | | | | | Support for: - build vector, - extract vector element, subvector, - insert vector element, subvector, - shuffle. llvm-svn: 319901
* [Hexagon] Remove HexagonISD::PACKHLKrzysztof Parzyszek2017-11-291-1/+0
| | | | llvm-svn: 319352
* [Hexagon] Create helpers extractVector and insertVector in loweringKrzysztof Parzyszek2017-11-291-4/+21
| | | | llvm-svn: 319351
* [Hexagon] Implement buildVector32 and buildVector64 as utility functionsKrzysztof Parzyszek2017-11-221-0/+5
| | | | | | | | | Change LowerBUILD_VECTOR to use those functions. This commit will tempora- rily affect constant vector generation (it will generate constant-extended values instead of non-extended combines), but the code for the general case should be better. The constant selection part will be fixed later. llvm-svn: 318877
* Fix a bunch more layering of CodeGen headers that are in TargetDavid Blaikie2017-11-171-1/+1
| | | | | | | | All these headers already depend on CodeGen headers so moving them into CodeGen fixes the layering (since CodeGen depends on Target, not the other way around). llvm-svn: 318490
OpenPOWER on IntegriCloud