search for: siinstrinfo

.../Target/AMDGPU/AMDGPUISelLowering.cpp | 1 + > lib/Target/AMDGPU/AMDGPUISelLowering.h | 1 + > lib/Target/AMDGPU/CIInstructions.td | 3 +- > lib/Target/AMDGPU/SIISelLowering.cpp | 41 +++++++++++++++ > lib/Target/AMDGPU/SIISelLowering.h | 1 + > lib/Target/AMDGPU/SIInstrInfo.td | 9 ++++ > lib/Target/AMDGPU/SIInstructions.td | 2 +- > test/CodeGen/AMDGPU/global_atomics.ll | 89 ++++++++++++++++++++++++++++++++ > 8 files changed, 145 insertions(+), 2 deletions(-) > > diff --git a/lib/Target/AMDGPU/AMDGPUISelLowering.cpp b/lib/Target/AMD...

Hi Tom, Matt, I'm working on a project that needs few coherent atomic operations (HSA mode: load, store, compare-and-swap) for std::atomic_uint in HCC. the attached patch implements atomic compare and swap for SI+ (untested). I tried to stay within what was available, but there are few issues that I was unsure how to address: 1.) it currently uses v2i32 for both input and output. This

...new virtual registers, which can not be allocated a range as this whole thing is called _after_ all reg selection is complete. If I'm right in this, I do not see how the in-tree target AMDGPU::SI has not been affected, as it creates virtual registers in both load and store stack operations in SIInstrInfo.cpp - which is where I confirmed to myself that it was okay to do so. When compilation broke, http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20130812/184331.htm l further suggested that the intention is that you can... but I do not see how a hoist can ever pass verification/compile correc...

...didn't figure out how > to do this. Anybody has idea on this? > In the AMDGPU backend we select everything we can to scalar instructions, and then after instruction selection, we move non-uniform values to the vector ALU. This is done by the SIFixSGPRCopiesPass, which relies heavily on SIInstrInfo::moveToVALU(). -Tom > - Ruiling

...> > > > > > > In the AMDGPU backend we select everything we can to scalar > > instructions, and then after instruction selection, we move > > non-uniform values to the vector ALU. This is done by > > the SIFixSGPRCopiesPass, which relies heavily on > > SIInstrInfo::moveToVALU(). > > Hi Tom, > > I take a look at the code, it looks like a good idea. It really helps me a lot. Thanks Tom! I have a question for the code, why it only pass copy-like instructions as TopInst to moveToALU()? Is there any special reason to do like this? I thought that ite...

...do this. Anybody has idea on this? > > > > In the AMDGPU backend we select everything we can to scalar > instructions, and then after instruction selection, we move > non-uniform values to the vector ALU. This is done by > the SIFixSGPRCopiesPass, which relies heavily on > SIInstrInfo::moveToVALU(). Hi Tom, I take a look at the code, it looks like a good idea. It really helps me a lot. Thanks Tom! I have a question for the code, why it only pass copy-like instructions as TopInst to moveToALU()? Is there any special reason to do like this? I thought that iterating through all t...

...an if statement like if(RegOp.isInlineImm()) // because 0.5 is this case contiune; before the statement to empty the modifier (RegOp.setModifiers(0);), it obvious does not work and cause the other matching fails. Does it mean to modify other files in other places, such as the VOP3Inst in the SIInstrInfo.td, or is this nothing to do with the MatchOperandParserImpl method or the other tablegen'd files. I'll be grateful for any idea you might give me to work around this. Regards, 李弘宇 (Li, Hong-Yu) Department of Computer Science & Information Engineering National Taiwan University -Mat...

...> > > In the AMDGPU backend we select everything we can to scalar > > > instructions, and then after instruction selection, we move > > > non-uniform values to the vector ALU. This is done by > > > the SIFixSGPRCopiesPass, which relies heavily on > > > SIInstrInfo::moveToVALU(). > > > > Hi Tom, > > > > I take a look at the code, it looks like a good idea. It really helps me a lot. Thanks Tom! I have a question for the code, why it only pass copy-like instructions as TopInst to moveToALU()? Is there any special reason to do like this...

Hi All. This is an RFC for a proposed target specific X86 optimization for reducing code size in the encoding of AVX-512 instructions when possible. When the AVX512F instruction set was introduced in X86 it included additional 32 registers of 512bit size each ZMM0 - ZMM31, as well as additional 16 XMM registers XMM16-XMM31 and 16 YMM registers YMM16-YMM31. In order to encode the new registers of

...make mapping tables like this. For examples, grep > for InstrMapping in: > > lib/Target/Hexagon/Hexagon.td > lib/Target/Mips/MipsDSPInstrFormats.td > lib/Target/Mips/MipsInstrFormats.td > lib/Target/Mips/Mips32r6InstrFormats.td > lib/Target/PowerPC/PPC.td > lib/Target/AMDGPU/SIInstrInfo.td > lib/Target/AMDGPU/R600Instructions.td > lib/Target/SystemZ/SystemZInstrFormats.td > lib/Target/Lanai/LanaiInstrInfo.td > > I've used this feature a few times in the PowerPC backend, and it's quite > convenient. > > -Hal > > No need for special Opt flags,...

Hi, I am working on a new LLVM target for Intel GPU, which also has same kind of scalar/vector register classes used in AMDGPU target. Like for a i32 virtual register, it will be held in scalar register if its value is uniform across a wavefront/warp, otherwise it will be in a vector register. Does AMDGPU already done this? I read the code, but I didn't figure out how to do this. Anybody has

...ature that is specifically designed to make mapping tables like this. For examples, grep for InstrMapping in: lib/Target/Hexagon/Hexagon.td lib/Target/Mips/MipsDSPInstrFormats.td lib/Target/Mips/MipsInstrFormats.td lib/Target/Mips/Mips32r6InstrFormats.td lib/Target/PowerPC/PPC.td lib/Target/AMDGPU/SIInstrInfo.td lib/Target/AMDGPU/R600Instructions.td lib/Target/SystemZ/SystemZInstrFormats.td lib/Target/Lanai/LanaiInstrInfo.td I've used this feature a few times in the PowerPC backend, and it's quite convenient. -Hal No need for special Opt flags, as it is always better to use the reduced VEX e...

...ature that is specifically designed to make mapping tables like this. For examples, grep for InstrMapping in: lib/Target/Hexagon/Hexagon.td lib/Target/Mips/MipsDSPInstrFormats.td lib/Target/Mips/MipsInstrFormats.td lib/Target/Mips/Mips32r6InstrFormats.td lib/Target/PowerPC/PPC.td lib/Target/AMDGPU/SIInstrInfo.td lib/Target/AMDGPU/R600Instructions.td lib/Target/SystemZ/SystemZInstrFormats.td lib/Target/Lanai/LanaiInstrInfo.td I've used this feature a few times in the PowerPC backend, and it's quite convenient. -Hal No need for special Opt flags, as it is always better to use the reduced VEX en...

...t;>> >>> In the AMDGPU backend we select everything we can to scalar >>> instructions, and then after instruction selection, we move >>> non-uniform values to the vector ALU. This is done by >>> the SIFixSGPRCopiesPass, which relies heavily on >>> SIInstrInfo::moveToVALU(). >> Hi Tom, >> >> I take a look at the code, it looks like a good idea. It really helps me > a lot. Thanks Tom! I have a question for the code, why it only pass > copy-like instructions as TopInst to moveToALU()? Is there any special > reason to do like this...

...ib/Target/AMDGPU/SICodeEmitter.cpp > llvm/trunk/lib/Target/AMDGPU/SIGenRegisterInfo.pl > llvm/trunk/lib/Target/AMDGPU/SIISelLowering.cpp > llvm/trunk/lib/Target/AMDGPU/SIISelLowering.h > llvm/trunk/lib/Target/AMDGPU/SIInstrFormats.td > llvm/trunk/lib/Target/AMDGPU/SIInstrInfo.cpp > llvm/trunk/lib/Target/AMDGPU/SIInstrInfo.h > llvm/trunk/lib/Target/AMDGPU/SIInstrInfo.td > llvm/trunk/lib/Target/AMDGPU/SIInstructions.td > llvm/trunk/lib/Target/AMDGPU/SIIntrinsics.td > llvm/trunk/lib/Target/AMDGPU/SIMachineFunctionInfo.cpp > llvm/tr...

Dear Developers, I compile a OpenCL kernel, FFT, in AMDAPP SDK v2.5 using clang 3.8 + libclc and assembling the code with lld (The LLVM linker). The assembly code contains the following assembly codes (and lots of other similar format assembly) that fails to be parsed by AMDGPUAsmParser. It seems to me that both are valid instructions after looking at the SI instruction spec. s_mov_b32 s0,

...is whole thing is > called > > _after_ all reg selection is complete. > > > > If I'm right in this, I do not see how the in-tree target AMDGPU::SI has > not > > been affected, as it creates virtual registers in both load and store > stack > > operations in SIInstrInfo.cpp - which is where I confirmed to myself > that it > > was okay to do so. When compilation broke, > > > http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20130812/184331.htm > > l further suggested that the intention is that you can... but I do not > see > &gt...