summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/Hexagon
Commit message (Collapse)AuthorAgeFilesLines
...
* Implementation of asm-goto support in LLVMCraig Topper2019-02-082-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | This patch accompanies the RFC posted here: http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html This patch adds a new CallBr IR instruction to support asm-goto inline assembly like gcc as used by the linux kernel. This instruction is both a call instruction and a terminator instruction with multiple successors. Only inline assembly usage is supported today. This also adds a new INLINEASM_BR opcode to SelectionDAG and MachineIR to represent an INLINEASM block that is also considered a terminator instruction. There will likely be more bug fixes and optimizations to follow this, but we felt it had reached a point where we would like to switch to an incremental development model. Patch by Craig Topper, Alexander Ivchenko, Mikhail Dvoretckii Differential Revision: https://reviews.llvm.org/D53765 llvm-svn: 353563
* [AsmPrinter] Remove hidden flag -print-schedule.Andrea Di Biagio2019-02-042-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes hidden codegen flag -print-schedule effectively reverting the logic originally committed as r300311 (https://llvm.org/viewvc/llvm-project?view=revision&revision=300311). Flag -print-schedule was originally introduced by r300311 to address PR32216 (https://bugs.llvm.org/show_bug.cgi?id=32216). That bug was about adding "Better testing of schedule model instruction latencies/throughputs". These days, we can use llvm-mca to test scheduling models. So there is no longer a need for flag -print-schedule in LLVM. The main use case for PR32216 is now addressed by llvm-mca. Flag -print-schedule is mainly used for debugging purposes, and it is only actually used by x86 specific tests. We already have extensive (latency and throughput) tests under "test/tools/llvm-mca" for X86 processor models. That means, most (if not all) existing -print-schedule tests for X86 are redundant. When flag -print-schedule was first added to LLVM, several files had to be modified; a few APIs gained new arguments (see for example method MCAsmStreamer::EmitInstruction), and MCSubtargetInfo/TargetSubtargetInfo gained a couple of getSchedInfoStr() methods. Method getSchedInfoStr() had to originally work for both MCInst and MachineInstr. The original implmentation of getSchedInfoStr() introduced a subtle layering violation (reported as PR37160 and then fixed/worked-around by r330615). In retrospect, that new API could have been designed more optimally. We can always query MCSchedModel to get the latency and throughput. More importantly, the "sched-info" string should not have been generated by the subtarget. Note, r317782 fixed an issue where "print-schedule" didn't work very well in the presence of inline assembly. That commit is also reverted by this change. Differential Revision: https://reviews.llvm.org/D57244 llvm-svn: 353043
* [opaque pointer types] Pass function types to CallInst creation.James Y Knight2019-02-013-4/+4
| | | | | | | | | This cleans up all CallInst creation in LLVM to explicitly pass a function type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57170 llvm-svn: 352909
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-02-011-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc doesn't choke on it, hopefully. Original Message: The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352827
* [Hexagon] Rename textually included file from .h to .incRichard Trieu2019-01-312-1/+1
| | | | llvm-svn: 352802
* Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."James Y Knight2019-01-311-2/+4
| | | | | | | | | This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791). Seems to run into compilation failures with GCC (but not clang, where I tested it). Reverting while I investigate. llvm-svn: 352800
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-01-311-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352791
* [Hexagon] Remove incorrect bit negationKrzysztof Parzyszek2019-01-231-1/+1
| | | | llvm-svn: 351956
* Reapply "IR: Add fp operations to atomicrmw"Matt Arsenault2019-01-221-2/+17
| | | | | | | This reapplies commits r351778 and r351782 with RISCV test fixes. llvm-svn: 351850
* Revert r351778: IR: Add fp operations to atomicrmwChandler Carruth2019-01-221-17/+2
| | | | | | | | | | | | | 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
* IR: Add fp operations to atomicrmwMatt Arsenault2019-01-221-2/+17
| | | | | | Add just fadd/fsub for now. llvm-svn: 351778
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-19150-600/+450
| | | | | | | | | | | | | | | | | 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
* [Hexagon] Do not promote terminator instructions in Hexagon loop idiomsKrzysztof Parzyszek2019-01-161-1/+3
| | | | llvm-svn: 351369
* [opaque pointer types] Remove some calls to generic Type subtype accessors.James Y Knight2019-01-101-5/+2
| | | | | | | | | | | | That is, remove many of the calls to Type::getNumContainedTypes(), Type::subtypes(), and Type::getContainedType(N). I'm not intending to remove these accessors -- they are useful/necessary in some cases. However, removing the pointee type from pointers would potentially break some uses, and reducing the number of calls makes it easier to audit. llvm-svn: 350835
* [LoopIdioms] More LocationSize::precise annotations; NFCGeorge Burgess IV2018-12-241-1/+2
| | | | | | | | | Both of these places reference memset-like loops. Memset is precise. Trying to keep these patches super small so they're easily post-commit verifiable, as requested in D44748. llvm-svn: 350044
* [Hexagon] Add patterns for funnel shiftsKrzysztof Parzyszek2018-12-202-3/+96
| | | | llvm-svn: 349770
* [Hexagon] Add patterns for shifts of v2i16Krzysztof Parzyszek2018-12-141-0/+12
| | | | | | This fixes https://llvm.org/PR39983. llvm-svn: 349202
* [Hexagon] Use IMPLICIT_DEF to any-extend 32-bit values to 64 bitsKrzysztof Parzyszek2018-12-141-23/+25
| | | | llvm-svn: 349199
* [Hexagon] Couple of fixes in optimize addressing modeKrzysztof Parzyszek2018-12-101-16/+21
| | | | | | | | | | - Check if an operand is an immediate before calling getImm. Some operands that take constant values can actually have global symbols or other constant expressions. - When a load-constant instruction can be folded into users, make sure to only delete it when all users have been successfully converted. llvm-svn: 348802
* Revert "[Hexagon] Check if operand is an immediate before getImm"Krzysztof Parzyszek2018-12-101-15/+12
| | | | | | This reverts r348787. The patch wasn't quite correct. llvm-svn: 348792
* [Hexagon] Check if operand is an immediate before getImmKrzysztof Parzyszek2018-12-101-12/+15
| | | | llvm-svn: 348787
* [Hexagon] Add patterns for any_extend from i1 and short vectors of i1Krzysztof Parzyszek2018-12-101-29/+28
| | | | llvm-svn: 348785
* [Hexagon] Fix post-ra expansion of PS_wselectKrzysztof Parzyszek2018-12-071-1/+0
| | | | llvm-svn: 348655
* [Targets] Add errors for tiny and kernel codemodel on targets that don't ↵David Green2018-12-071-7/+2
| | | | | | | | | | | 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
* Fix gcc7.3 -Wparentheses warning. NFCI.Simon Pilgrim2018-12-071-3/+3
| | | | llvm-svn: 348581
* [Hexagon] Add intrinsics for Hexagon V66Krzysztof Parzyszek2018-12-051-0/+30
| | | | llvm-svn: 348413
* [Hexagon] Add instruction definitions for Hexagon V66Krzysztof Parzyszek2018-12-0516-500/+2763
| | | | llvm-svn: 348411
* [Hexagon] Foundation of support for Hexagon V66Krzysztof Parzyszek2018-12-0514-125/+226
| | | | llvm-svn: 348407
* [Hexagon] Remove unused checker functions from asm parserKrzysztof Parzyszek2018-12-041-2/+0
| | | | llvm-svn: 348269
* Fix MSVC "unknown pragma" warning. NFCI.Simon Pilgrim2018-12-041-0/+6
| | | | llvm-svn: 348256
* [Hexagon] Switch to auto-generated intrinsic definitions and patternsKrzysztof Parzyszek2018-12-033-1233/+3613
| | | | llvm-svn: 348206
* [Hexagon] Extract operand decoders into a separate file, NFCKrzysztof Parzyszek2018-12-032-56/+74
| | | | | | | These decoders are automatically generated. Keeping them separated makes updating architectures easier. llvm-svn: 348196
* [Hexagon] Remove unused encodings, NFCKrzysztof Parzyszek2018-12-031-741/+114
| | | | llvm-svn: 348193
* [Hexagon] Update timing classesKrzysztof Parzyszek2018-12-035-5770/+5651
| | | | llvm-svn: 348183
* [Hexagon] Change instruction type field in TSFlags to 7 bitsKrzysztof Parzyszek2018-12-035-182/+177
| | | | llvm-svn: 348171
* [Hexagon] Add HasV5 predicate for compatibility with auto-generated filesKrzysztof Parzyszek2018-12-031-6/+6
| | | | llvm-svn: 348167
* [Hexagon] Remove unused operand definitions, NFCKrzysztof Parzyszek2018-12-031-8/+1
| | | | llvm-svn: 348163
* [Hexagon] Some formatting changes, NFCKrzysztof Parzyszek2018-12-032-5/+3
| | | | llvm-svn: 348162
* [CodeGen][NFC] Make `TII::getMemOpBaseImmOfs` return a base operandFrancis Visoiu Mistrih2018-11-283-27/+30
| | | | | | | | | | | | | | | | | | Currently, instructions doing memory accesses through a base operand that is not a register can not be analyzed using `TII::getMemOpBaseRegImmOfs`. This means that functions such as `TII::shouldClusterMemOps` will bail out on instructions using an FI as a base instead of a register. The goal of this patch is to refactor all this to return a base operand instead of a base register. Then in a separate patch, I will add FI support to the mem op clustering in the MachineScheduler. Differential Revision: https://reviews.llvm.org/D54846 llvm-svn: 347746
* [x86] allow vector load narrowing with multi-use valuesSanjay Patel2018-11-101-0/+4
| | | | | | | | | | | | | | | | | | | | | | This is a long-awaited follow-up suggested in D33578. Since then, we've picked up even more opportunities for vector narrowing from changes like D53784, so there are a lot of test diffs. Apart from 2-3 strange cases, these are all wins. I've structured this to be no-functional-change-intended for any target except for x86 because I couldn't tell if AArch64, ARM, and AMDGPU would improve or not. All of those targets have existing regression tests (4, 4, 10 files respectively) that would be affected. Also, Hexagon overrides the shouldReduceLoadWidth() hook, but doesn't show any regression test diffs. The trade-off is deciding if an extra vector load is better than a single wide load + extract_subvector. For x86, this is almost always better (on paper at least) because we often can fold loads into subsequent ops and not increase the official instruction count. There's also some unknown -- but potentially large -- benefit from using narrower vector ops if wide ops are implemented with multiple uops and/or frequency throttling is avoided. Differential Revision: https://reviews.llvm.org/D54073 llvm-svn: 346595
* [Hexagon] Fix some -Wunused-function with LLVM_DUMP_METHOD and -Wunused-variableFangrui Song2018-11-092-4/+9
| | | | llvm-svn: 346543
* [Hexagon] Fix unused variable warning in release buildsJordan Rupprecht2018-11-091-0/+1
| | | | llvm-svn: 346537
* [Hexagon] Implement noreturn optimizationBrendon Cahoon2018-11-094-1/+39
| | | | | | | | | | | Eliminate the stack frame in functions with the noreturn nounwind attributes, and when the noreturn-stack-elim target feature is enabled. This reduces the code and stack space needed for noreturn functions. Differential Revision: https://reviews.llvm.org/D54210 llvm-svn: 346532
* [Hexagon] Place globals with explicit .sdata section in small dataKrzysztof Parzyszek2018-11-091-5/+10
| | | | | | | | Both -fPIC and -G0 disable placement of globals in small data section, but if a global has an explicit section assigmnent placing it in small data, it should go there anyway. llvm-svn: 346523
* LivePhysRegs/IfConversion: Change some types from unsigned to MCPhysReg; NFCMatthias Braun2018-11-061-1/+1
| | | | | | | | Change the type in a couple of lists and sets that only store physical registers from unsigned to MCPhysRegs. The later is only 16bits and saves us a bit of memory. llvm-svn: 346254
* [TargetLowering] Change TargetLoweringBase::getPreferredVectorAction to take ↵Craig Topper2018-11-053-4/+4
| | | | | | | | 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
* [SelectionDAG] Remove special methods for creating *_EXTEND_VECTOR_INREG ↵Craig Topper2018-11-041-1/+2
| | | | | | | | | | nodes. Move asserts into getNode. These methods were just wrappers around getNode with additional asserts (identical and repeated 3 times). But getNode already has a switch that can be used to hold these asserts that allows them to be shared for all 3 opcodes. This also enables checking on the places that create these nodes without using the wrappers. The rest of the patch is just changing all callers to use getNode directly. llvm-svn: 346087
* [Hexagon] Do not reduce load size for globals in small-dataKrzysztof Parzyszek2018-11-022-0/+18
| | | | | | | | | | | | 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
* [Hexagon] Remove unintended fallthrough from MC duplex codeReid Kleckner2018-11-011-5/+5
| | | | | | | | | | | | I added these annotations in r345878 because I wasn't sure if the fallthrough was intended. Krzysztof Parzyszek confirmed that they should be breaks, so that's what this patch does. Reviewers: kparzysz Differential Revision: https://reviews.llvm.org/D53991 llvm-svn: 345883
* Fix clang -Wimplicit-fallthrough warnings across llvm, NFCReid Kleckner2018-11-015-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch should not introduce any behavior changes. It consists of mostly one of two changes: 1. Replacing fall through comments with the LLVM_FALLTHROUGH macro 2. Inserting 'break' before falling through into a case block consisting of only 'break'. We were already using this warning with GCC, but its warning behaves slightly differently. In this patch, the following differences are relevant: 1. GCC recognizes comments that say "fall through" as annotations, clang doesn't 2. GCC doesn't warn on "case N: foo(); default: break;", clang does 3. GCC doesn't warn when the case contains a switch, but falls through the outer case. I will enable the warning separately in a follow-up patch so that it can be cleanly reverted if necessary. Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu Differential Revision: https://reviews.llvm.org/D53950 llvm-svn: 345882
OpenPOWER on IntegriCloud