search for: sgpr

> 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:

...ontextually, a real boolean value will either be a 1-bit scalar condition (in a non-allocatable physical condition register, which will need to be copied to an allocatable class 32-bit vreg during selection), or a vector condition where the s1 will really be a lane mask of results in a 32 or 64-bit SGPR. This will be known during RegBankSelect. To represent this, I’m using two different pseudo register banks used for operands that really function as booleans (select/br conditions, compare results, and a few intrinsics). These two banks physically alias the SGPR bank, but contextually function diff...

...lvm-dev It's both "No such file or directory" and "Patch does not apply" > > Creating svn staging directory: (.git/llvm-upstream-svn) > svn staging area ready in '.git/llvm-upstream-svn' > Pushing 1 commit: > 4e1be4c8956 [AMDGPU] Increases available SGPR for Calling Convention > `git apply -p1 -` returned 1 > b'error: lib/Target/AMDGPU/AMDGPUCallingConv.td: No such file or > directory\nerror: lib/Target/AMDGPU/AMDGPUISelLowering.cpp: No such file or > directory\n<stdin>:345: new blank line at EOF.\n+' > Patch doesn'...

Thanks Paul but I saw that on a previous email chain and tried it, it did not work for me. I also saw there are issues with svn tags on some files? Thanks, Ryan On Tue, May 14, 2019, 1:30 PM <paul.robinson at sony.com> wrote: > It has been a while since I've seen "No such file or directory" although I > do still occasionally see "Patch doesn't apply"

...hat you lie by saying that bank1 is legal in that case? > If so, why applyMapping would do any rewriting since this is legal. Yes. It’s what happens here: https://reviews.llvm.org/D58511 <https://reviews.llvm.org/D58511> For extract_vector_elt, the indirect register index type must be an SGPR. I’ve implemented the mapping as just copying the original source bank and allowing applyMapping to deal with it. There might be cases that aren’t correctly being rewritten, but I haven’t finished handling every case to run into them yet. > >> This sort of makes sense, since it is legal...

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: > >

...erspective, there is 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 = IS...

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#

Hi, Some operations on AMDGPU require operands which must be in a register bank that is impossible to copy from another. The operation needs to be rewritten in a complex way to avoid the illegal copy. Currently if I correctly report the required register banks in the operand mapping, RegBankSelect happily inserts the illegal copies, somehow concluding they are cheap (I would at least hope

Hi, I'm trying to write an LLVM backend for Epiphany arch, and I wonder if someone can give me some advice on how to implement load/store optimization. The CPU itself is 32-bit, but it supports wider 64-bit loads and store. So the basic idea is to make use of those by combining narrow ones. I've checked how it is done in AArch64 and Hexagon, and my current code is very close to the

...lt;escha at apple.com>: > 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, >...