search for: vgpr

Hi, I’m looking at RegBankSelect’s partially implemented support for deciding to split a value between multiple registers and I’m wondering if it’s actually intended to solve the problem I’m trying to use it for. RegisterBankInfo.h has this example mapping table: /// E.g., /// Let say we have a 32-bit add and a <2 x 32-bit> vadd. We /// can expand the /// <2 x 32-bit> add into

> On Feb 26, 2019, at 7:25 PM, Quentin Colombet <qcolombet at apple.com> wrote: > > > >> On Feb 26, 2019, at 4:18 PM, Matt Arsenault <arsenm2 at gmail.com <mailto:arsenm2 at gmail.com>> wrote: >> >> >> >>> On Feb 26, 2019, at 7:01 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote:

I have some code such that: vgpr1 = mov 0 branch bb bb: PHI vgpr2 = vgpr1, …. PHI vgpr3 = vgpr1, …. PHI vgpr4 = vgpr1, …. PHI vgpr5 = vgpr1, …. PHI node elimination is generating copies for all these PHIs (and hoisting them) as such: vgpr1 = 0 vgpr20 = COPY vgpr1 // old vgpr2 vgpr30 = COPY vgpr1 // old vgpr3 vgpr40 = COPY vgpr1...

...3.6-release project on phabricator, so if you would like to propose a patch via phabricator you can create a new diff and select '3.6-release' as the project. Also make sure to include the ToT revision number in the subject, something like: Merge r237164 to 3.6 branch: R600/SI: Fix bug in VGPR spilling. I'm also trying to figure out a way to create a submission without a patch, because in most cases it is redundant to specify a revision number and upload a patch. If anyone has any suggestions about this, please let me know. Thanks, Tom

...it triggers a spill, then we rematerialize the immediate instead of holding a register for it. Cheers, -Quentin > On Nov 13, 2019, at 7:36 AM, Ryan Taylor via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I have some code such that: > > vgpr1 = mov 0 > branch bb > bb: > PHI vgpr2 = vgpr1, …. > PHI vgpr3 = vgpr1, …. > PHI vgpr4 = vgpr1, …. > PHI vgpr5 = vgpr1, …. > > PHI node elimination is generating copies for all these PHIs (and hoisting them) as such: > > vgpr1 =...

...nstead of holding a register for it. > > > > Cheers, > > -Quentin > > > >> On Nov 13, 2019, at 7:36 AM, Ryan Taylor via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> > >> I have some code such that: > >> > >> vgpr1 = mov 0 > >> branch bb > >> bb: > >> PHI vgpr2 = vgpr1, …. > >> PHI vgpr3 = vgpr1, …. > >> PHI vgpr4 = vgpr1, …. > >> PHI vgpr5 = vgpr1, …. > >> > >> PHI node elimination is generating copies for all these PHIs (and > hoist...

...;> > >> > Cheers, >> > -Quentin >> > >> >> On Nov 13, 2019, at 7:36 AM, Ryan Taylor via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> >> >> I have some code such that: >> >> >> >> vgpr1 = mov 0 >> >> branch bb >> >> bb: >> >> PHI vgpr2 = vgpr1, …. >> >> PHI vgpr3 = vgpr1, …. >> >> PHI vgpr4 = vgpr1, …. >> >> PHI vgpr5 = vgpr1, …. >> >> >> >> PHI node elimination is generating copies fo...

On Mon, Nov 4, 2019 at 12:18 PM Quentin Colombet <qcolombet at apple.com> wrote: > Hi Alex, > > Thanks for reporting this. > Wei worked on the hoisting optimization. > > @Wei, could you work with Alex to see what is the problem. > > Cheers, > -Quentin > > > On Nov 3, 2019, at 5:20 AM, via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > >

...just one sALU and one vALU. Programs written for Southern Islands intermix sALU and vALU instructions and all instructions are executed in order no matter what ALU the are executed on, so there is no synchronization needed between the ALUs. Each ALU has its own register file: SGPRs for sALU, and VGPRs for vALU. The vALU can read from VGPRs and also SGPRs, but the sALU can only read from SGPRs. This restriction on the sALU seems to be causing the instruction selector to generate some illegal copies, which is the main problem I'm trying to solve. For example: NODE0 = ISD::ADD SGPR0, VGPR0...

Hi Escha, Great to have your comment! Do you have any specific reason for not doing like this? I am not sure whether I understand your point correctly. For "just model one thread", do you mean "only considering ONE of the 8/16 working lanes that running in lock-step way"?? For my case, may be something like I only need to define r0~r127 as register for i32 register (each r#

...s.td b/lib/Target/AMDGPU/CIInstructions.td > index 593300f..d99b013 100644 > --- a/lib/Target/AMDGPU/CIInstructions.td > +++ b/lib/Target/AMDGPU/CIInstructions.td > @@ -156,7 +156,7 @@ defm FLAT_ATOMIC_SWAP : FLAT_ATOMIC < > flat<0x30, 0x40>, "flat_atomic_swap", VGPR_32 > >; > defm FLAT_ATOMIC_CMPSWAP : FLAT_ATOMIC < > - flat<0x31, 0x41>, "flat_atomic_cmpswap", VGPR_32, VReg_64 > + flat<0x31, 0x41>, "flat_atomic_cmpswap", VReg_64 > >; > defm FLAT_ATOMIC_ADD : FLAT_ATOMIC < > flat<0x32,...

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

...I-CHECK: S_ADDC_U32 > +; SI: S_ADD_U32 > +; SI: S_ADDC_U32 > + > +; EG-DAG: ADD_INT > +; EG-DAG: ADDC_UINT > +; EG-DAG: ADD_INT > define void @add64(i64 addrspace(1)* %out, i64 %a, i64 %b) { > entry: > %0 = add i64 %a, %b > @@ -132,7 +136,11 @@ entry: > ; to a VGPR before doing the add. > > ; FUNC-LABEL: @add64_sgpr_vgpr > -; SI-CHECK-NOT: V_ADDC_U32_e32 s > +; SI-NOT: V_ADDC_U32_e32 s > + > +; EG-DAG: ADD_INT > +; EG-DAG: ADDC_UINT > +; EG-DAG: ADD_INT > define void @add64_sgpr_vgpr(i64 addrspace(1)* %out, i64 %a, i64 addrspace...

...;: > If I understand right, on this arch, ‘uniform’ refers to values that only > take one lane of register file instead of SIMD-width lanes, and they > *share* the same region of the register file as non-uniform values. This is > in contrast to e.g. AMDGPU where SGPRs (scalar GPRs) and VGPRs are separate > register files. > > If this understanding is correct, you may be able to define uniform and > non-uniform registers separately, but make sure that one aliases the other, > e.g. so that (if your SIMD width is 16) VGPR 20 overlaps SGPR 320, > 321….335. So you can hav...

...amp;G_w%C*ef) zwj0;<Je;9DGW<xK_T}$W?O8WX`3zkq>Z)j;7x%x`3g4?{4-Q0pH8^hv+6~QZ`&(Ax z3CB7LcLrx<%?#2}#u|S^;h>=<sMAE;CiEG68V*IQM@~Cm{)eOWzmw;hm&bI0i|c>O znwu*Ug$j$=SETds*MmWv=?Xx}%6H|o+TgtSdofzK$0WjvtZ;?vJ*<LfJ9+rLNHAD( zY(Ft9{?E1R3{gF_QxquiR!=<0jo^{dX8bxA+lpU-c#B(|-O0%vgPr|=;of-4Tmv;e zV-;Az*^jurY0%>Uyn8(10H>Du>~(AV!dhwc5Z(M4PTU*Xsi77!<ea^CG$;B@e+!W? z3-N+iVIXK>iUQwz-?OmL0Vm(3=KU@KrONIXP0q_0>V?Py2ub5XmgQh}VPO$+M!3?j zMD{R&e;7g03haVk(1OYe7nJ=<g%<QeO(-rI$)>l)b%C6Og3cIuD$|J$ilnU2Z;LDE zulW0PGNSclVSUvd$aky(hRd3&a1%W_br!!_X8eXwqRIbsN<...