summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/AMDGPU
Commit message (Collapse)AuthorAgeFilesLines
...
* AMDGPU/GlobalISel: Fix non-power-of-2 implicit_defMatt Arsenault2019-02-081-1/+2
| | | | llvm-svn: 353522
* AMDGPU/GlobalISel: Don't use a copy in addrspacecast loweringMatt Arsenault2019-02-081-1/+1
| | | | llvm-svn: 353516
* [AMDGPU][MC][CODEOBJECT] Added predefined symbols to access GPU minor and ↵Dmitry Preobrazhensky2019-02-081-0/+4
| | | | | | | | | | | | | | stepping numbers Added the following Code Object v3 symbols: .amdgcn.gfx_generation_minor .amdgcn.gfx_generation_stepping Reviewers: artem.tamazov, kzhuravl Differential Revision: https://reviews.llvm.org/D57826 llvm-svn: 353515
* [AMDGPU] Fix DPP combinerValery Pykhtin2019-02-083-96/+175
| | | | | | | | | | | | | Differential revision: https://reviews.llvm.org/D55444 dpp move with uses and old reg initializer should be in the same BB. bound_ctrl:0 is only considered when bank_mask and row_mask are fully enabled (0xF). Otherwise the old register value is checked for identity. Added add, subrev, and, or instructions to the old folding function. Kill flag is cleared for the src0 (DPP register) as it may be copied into more than one user. The pass is still disabled by default. llvm-svn: 353513
* AMDGPU/GlobalISel: Legalize addrspacecastMatt Arsenault2019-02-083-1/+190
| | | | | | | Use a placeholder constant for now on targets that need the load from the queue ptr. llvm-svn: 353497
* GlobalISel: Implement narrowScalar for shift main typeMatt Arsenault2019-02-071-3/+9
| | | | | | | | | | | | | | | This is pretty much directly ported from SelectionDAG. Doesn't include the shift by non-constant but known bits version, since there isn't a globalisel version of computeKnownBits yet. This shows a disadvantage of targets not specifically which type should be used for the shift amount. If type 0 is legalized before type 1, the operations on the shift amount type use the wider type (which are also less likely to legalize). This can be avoided by targets specifying legalization actions on type 1 earlier than for type 0. llvm-svn: 353455
* AMDGPU/GlobalISel: Restrict g_implicit_def legalityMatt Arsenault2019-02-071-8/+15
| | | | llvm-svn: 353452
* AMDGPU/GlobalISel: Legalize fsqrtMatt Arsenault2019-02-072-0/+13
| | | | llvm-svn: 353438
* AMDGPU/GlobalISel: Legalize some f16 operationsMatt Arsenault2019-02-071-4/+16
| | | | llvm-svn: 353436
* GlobalISel: Implement fewerElementsVector for shiftsMatt Arsenault2019-02-071-2/+7
| | | | | | | | | Introduce a new function which handles instructions with multiple type indices, but have the same number of vector elements. Also legalize v2s16 shifts when applicable. llvm-svn: 353432
* GlobalISel: Try to make legalize rules more useful for vectorsMatt Arsenault2019-02-071-18/+7
| | | | | | | Mostly keep the existing functions on scalars, but add versions which also operate based on the vector element size. llvm-svn: 353430
* [AMDGPU] Consider XOR in waterfall loop as a terminatorScott Linder2019-02-051-1/+1
| | | | | | | | Ensure the XOR in the waterfall loop for indirect addressing is considered a terminator. Differential Revision: https://reviews.llvm.org/D57703 llvm-svn: 353207
* AMDGPU: Fix assert on trunc from bitcast of build_vectorMatt Arsenault2019-02-051-1/+1
| | | | | | | | | The v2i64 argument is lowered to a bitcast of v4i32 build_vector. This would then attempt to use the i32-element as the source of the vector truncate. This really would need to collect 2 elements from the build_vector to produce the intended truncate. llvm-svn: 353202
* AMDGPU: Don't rematerialize mov with implicit operandsMatt Arsenault2019-02-041-1/+2
| | | | | | | This was pulling the mov used for register indexing on gfx9 out of the loop. llvm-svn: 353101
* [AMDGPU] Support emitting GOT relocations for function callsScott Linder2019-02-043-41/+20
| | | | | | Differential Revision: https://reviews.llvm.org/D57416 llvm-svn: 353083
* AMDGPU/GlobalISel: Legalize select for v4s16Matt Arsenault2019-02-041-3/+3
| | | | | | | Also add some more select tests to help show future legalization changes. llvm-svn: 353045
* [AMDGPU] Fix -Wunused-variable after rL352978Fangrui Song2019-02-031-1/+0
| | | | llvm-svn: 352982
* GlobalISel: Implement widenScalar for G_UNMERGE_VALUESMatt Arsenault2019-02-031-1/+2
| | | | | | | | | For the scalar case only. Also move the similar G_MERGE_VALUES handling to a separate function and cleanup to make them look more similar. llvm-svn: 352979
* GlobalISel: Implement widenScalar for G_EXTRACT vector sourcesMatt Arsenault2019-02-021-0/+18
| | | | | | Handle the basic element extract case. llvm-svn: 352978
* AMDGPU/GlobalISel: Avoid reporting illegal extloads as legalMatt Arsenault2019-02-021-1/+1
| | | | | | This avoids breaking a test in a future commit. llvm-svn: 352977
* AMDGPU/GlobalISel: Legalize icmp for pointer typesMatt Arsenault2019-02-021-1/+10
| | | | llvm-svn: 352976
* AMDGPU/GlobalISel: Legalize constant for pointer typesMatt Arsenault2019-02-021-3/+4
| | | | llvm-svn: 352975
* AMDGPU/GlobalISel: Legalize select for pointer typesMatt Arsenault2019-02-021-4/+12
| | | | llvm-svn: 352974
* GlobalISel: Legalization for inttoptr/ptrtointMatt Arsenault2019-02-021-6/+44
| | | | llvm-svn: 352973
* [opaque pointer types] Pass value type to GetElementPtr creation.James Y Knight2019-02-012-9/+6
| | | | | | | | | This cleans up all GetElementPtr creation in LLVM to explicitly pass a value type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57173 llvm-svn: 352913
* [opaque pointer types] Pass value type to LoadInst creation.James Y Knight2019-02-014-14/+15
| | | | | | | | | This cleans up all LoadInst creation in LLVM to explicitly pass the value type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57172 llvm-svn: 352911
* [AMDGPU] Fix for vector element insertionTim Corringham2019-02-011-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Incorrect code was generated when lowering insertelement operations for vectors with 8 or 16 bit elements. The value being inserted was not adjusted for the position of the element within the 32 bit word and so only the low element within each 32 bit word could receive the intended value. Fixed by simply replicating the value to each element of a congruent vector before the mask and or operation used to update the intended element. A number of affected LIT tests have been updated appropriately. before the mask & or into the intended Reviewers: arsenm, nhaehnle Reviewed By: arsenm Subscribers: llvm-commits, arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye Tags: #llvm Differential Revision: https://reviews.llvm.org/D57588 llvm-svn: 352885
* Provide reason messages for unviable inliningYevgeny Rouban2019-02-011-2/+3
| | | | | | | | | | | | | InlineCost's isInlineViable() is changed to return InlineResult instead of bool. This provides messages for failure reasons and allows to get more specific messages for cases where callsites are not viable for inlining. Reviewed By: xbolva00, anemet Differential Revision: https://reviews.llvm.org/D57089 llvm-svn: 352849
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-02-013-39/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."James Y Knight2019-01-313-41/+39
| | | | | | | | | 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-313-39/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* GlobalISel: Handle odd splits in fewerElementsVector for load/storeMatt Arsenault2019-01-311-1/+2
| | | | llvm-svn: 352720
* GlobalISel: Implement narrowScalar for bswapMatt Arsenault2019-01-311-1/+5
| | | | llvm-svn: 352719
* GlobalISel: Allow bitcount ops to have different result typeMatt Arsenault2019-01-311-5/+10
| | | | | | For AMDGPU the result is always 32-bit for 64-bit inputs. llvm-svn: 352717
* GlobalISel: Fix creating MMOs with align 0Matt Arsenault2019-01-311-2/+2
| | | | llvm-svn: 352712
* Add a 'dynamic' parameter to the objectsize intrinsicErik Pilkington2019-01-301-1/+2
| | | | | | | | | | | | | | This is meant to be used with clang's __builtin_dynamic_object_size. When 'true' is passed to this parameter, the intrinsic has the potential to be folded into instructions that will be evaluated at run time. When 'false', the objectsize intrinsic behaviour is unchanged. rdar://32212419 Differential revision: https://reviews.llvm.org/D56761 llvm-svn: 352664
* AMDGPU: Stop generating unused intrinsic .inc filesMatt Arsenault2019-01-301-2/+0
| | | | llvm-svn: 352635
* GlobalISel: Implement fewerElementsVector for selectMatt Arsenault2019-01-301-1/+20
| | | | llvm-svn: 352601
* AMDGPU/GlobalISel: Fix clamping shifts with 16-bit instsMatt Arsenault2019-01-301-2/+3
| | | | llvm-svn: 352599
* GlobalISel: Support narrowScalar for uneven loadsMatt Arsenault2019-01-301-0/+8
| | | | llvm-svn: 352594
* GlobalISel: Partially implement widenScalar for MERGE_VALUESMatt Arsenault2019-01-291-7/+8
| | | | llvm-svn: 352560
* GlobalISel: Fix narrowScalar for load/store with different mem sizeMatt Arsenault2019-01-291-2/+22
| | | | | | | | | | This was ignoring the memory size, and producing multiple loads/stores if the operand size was different from the memory size. I assume this is the intent of not having an explicit G_ANYEXTLOAD (although I think that would probably be better). llvm-svn: 352523
* Adjust documentation for git migration.James Y Knight2019-01-291-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes most references to the paths: llvm.org/svn/ llvm.org/git/ llvm.org/viewvc/ github.com/llvm-mirror/ github.com/llvm-project/ reviews.llvm.org/diffusion/ to instead point to https://github.com/llvm/llvm-project. This is *not* a trivial substitution, because additionally, all the checkout instructions had to be migrated to instruct users on how to use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of checking out various projects into various subdirectories. I've attempted to not change any scripts here, only documentation. The scripts will have to be addressed separately. Additionally, I've deleted one document which appeared to be outdated and unneeded: lldb/docs/building-with-debug-llvm.txt Differential Revision: https://reviews.llvm.org/D57330 llvm-svn: 352514
* [AMDGPU] Fix a weird WWM intrinsic issue.Neil Henning2019-01-292-17/+17
| | | | | | | | | | | I found a really strange WWM issue through a very convoluted shader that essentially boils down to a bug in SIInstrInfo where canReadVGPR did not correctly identify that WWM is like a copy and can have a VGPR as its source. Differential Revision: https://reviews.llvm.org/D56002 llvm-svn: 352500
* AMDGPU: Add DS append/consume intrinsicsMatt Arsenault2019-01-284-17/+94
| | | | | | | | | | | | | | | Since these pass the pointer in m0 unlike other DS instructions, these need to worry about whether the address is uniform or not. This assumes the address is dynamically uniform, and just uses readfirstlane to get a copy into an SGPR. I don't know if these have the same 16-bit add for the addressing mode offset problem on SI or not, but I've just assumed they do. Also includes some misc. changes to avoid test differences between the LDS and GDS versions. llvm-svn: 352422
* [AMDGPU] Add intrinsics for 16 bit interpolationTim Corringham2019-01-286-3/+96
| | | | | | | | | | | | | | | | | | | Summary: Added the intrinsics llvm.amdgcn.interp.p1.f16() and llvm.amdgcn.interp.p2.f16() and related LIT test. The p1 intrinsic generates code appropriate for both 16 and 32 bank LDS. Reviewers: #amdgpu, dstuttard, arsenm, tpr Reviewed By: #amdgpu, arsenm Subscribers: jvesely, mgorny, arsenm, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D46754 llvm-svn: 352357
* GlobalISel: Implement narrowScalar for mulMatt Arsenault2019-01-271-0/+1
| | | | llvm-svn: 352300
* GlobalISel: fewerElementsVector for intrinsic_trunc/intrinsic_roundMatt Arsenault2019-01-271-1/+2
| | | | llvm-svn: 352298
* AMDGPU/GlobalISel: Use scalarize instead of clampMaxNumElementsMatt Arsenault2019-01-261-2/+1
| | | | llvm-svn: 352297
* AMDGPU/GlobalISel: Legalize more bit opsMatt Arsenault2019-01-261-4/+7
| | | | llvm-svn: 352295
OpenPOWER on IntegriCloud