similar to: Spilling to register for a given register class

Ok, thanks. Except the question was meant slightly different. Less w.r.t. organizing the register classes, and more w.r.t. implementation. I've noticed for instance that when trying to model this straight forwardly by writing a vreg from spills and reading this from fills (not further elaborated here), that the spiller can't handle vreg def-use pairs: there are assertions making sure a

Thanks a lot for the suggestions! I will look into using vld1/vst1, sounds good. I am custom lowering the bitcasts, that's now the only place where FP_TO_FP16 and FP16_TO_FP nodes are created to avoid inefficient code generation. I will double check if I can't achieve the same without using these nodes (because I really would like to get completely rid of them). Cheers, Sjoerd.

I would like to revive this thread, as I am struggling a lot with the FP16 implementation in the ARM backend. My implementation in https://reviews.llvm.org/D38315 is finished (except one case), but a more robust alternative implementation was suggested. One can indeed argue that my current implementation is a bit fragile, because it involves manually patching up the isel dags for a few cases. The

Hi Sjoerd, For ISel, I think having a separate register class will give you less headache. I wondering if you could get away with not touching the instructions descriptions at all, instead defining external pattens for the FullFP16 case, like so: def VCVTBHS: ASuI<0b11101, 0b11, 0b0010, 0b01, 0, (outs SPR:$Sd), (ins SPR:$Sm), IIC_fpCVTSH, "vcvtb",

It does have an output register, it's just an implicit flag register. It still has a DAG output. I'm not sure if the allocatable bit matters at this point for selection purposes, but it does later. Not adding a type to the register class can also be problematic (e.g. a flag register should have i1 added to regTypes for its class). -Matt > Does LLVM make an assumption that there is an

Looks like spillAroundUses is spilling multiple duplicate copies to the stack, for example, with some regs we get 1 storeRegToStack call, for others we get multiple (2-6+) and then these instructions are never eliminated. Looking at spillAroundUses it looks like multiple duplicate COPYs are being generated, why? One for each use? The reg_bundle holds these multiple copies so that we are

Hi Ryan, > On Mar 14, 2016, at 7:49 AM, Ryan Taylor via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I looked at this again and it appears that while spillAroundUses sets the register as 'dead', there is no checking to see if it's dead in subsequent iterations of the bundle loop. > > Is this intentional? > > On Mon, Mar 7, 2016 at 3:28 PM, Ryan

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

This lets us spill more values and compile a big shader for Civilization 6. Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp index b33d7b4010..f29c8a1a95

[This feature addresses https://bugs.llvm.org/show_bug.cgi?id=37880 and https://github.com/KSPP/linux/issues/84.] Clang has been ramping up its support of the Linux kernel. We recently added "asm goto with outputs", a long requested feature. We want to continue building our relationship with the Linux community. KSPP is a project to improve security in the Linux kernel, through both

Hi, right now, LLVM does register spilling by: 1. Creating stack object 2. Passing index of that stack object to MRegisterInfo::storeRegToStackSlot 3. At later stage, frame indices are replaced by calling to MRegisterInfo::eliminateFrameIndex. This works for me, but there's slight problem. The target does not have "register + contant" addressing mode, so accessing frame index

On Jan 19, 2012, at 5:31 AM, Jonas Paulsson wrote: > LLVM would have to be extended with an RegClass/register-attribute 'spillable' What exactly are you proposing? Why can't you do what the PowerPC and Hexagon targets do? Spill-free register allocation sounds great, why not do it for all register classes? > , and a register allocator would have to implement register pairing.

> On Jan 19, 2012, at 5:31 AM, Jonas Paulsson wrote: > LLVM would have to be extended with an RegClass/register-attribute 'spillable' > > > What exactly are you proposing? Why can't you do what the PowerPC and Hexagon targets do? Yes, I can move a CR to a GPR and save it to the stack, but due to a very irregular register file this is about 10 times more expensive

LLVM can model some quite complicated register banks now, and we even use registers to model some encoding constraints. For example, a few ARM instructions like strexd have two register operands that must be an aligned pair of consecutive GPR registers (like r0, r1). This constraint is modeled with the GPRPair register class containing R0_R1, R2_R3, ... pseudo-registers. Sometimes ISAs also

Hello, I have a set of one-liners (many thanks to previous responses from this list) that I use to look at newly imported data sets with functions like dim(), names(), str(), etc. within lapply(). Generally, these commands work for me but, I am apparently still missing some aspect of list manipulation. I don't understand why I get a set of NULL list elements at the end of each output as

Hi, My target has special requirements during register allocation - there is both a need to handle register pairing and to never spill a flag result reg-class (which might happen at -O0 for no obvious reason). Since neither of these issues seems to be supported, I have tried to pre-allocate these registers in the preRA pass. This has resulted in "using undefined physical register"

Hello, I have count data that illustrate the presence or absence of individuals in my study population. I created a grid cell across the study area and calcuated a count value for each individual per season per year for each grid cell. The count value is the number of time an individual was present in each grid cell. For illustration my data columns look something like this and are repeated for

Dear experts, when trying to estimate an kernel density function with density(x) I get the following error message with imported data from either EXCEL or text files: Error in density(spr) : argument must be numeric. Other procedues such as truehist work. If I generate data within R density works fine. Does anybody have an idea? Yours -- Christoph Hanck Wissenschaftliche Hilfskraft

s/llvm-commits/llvmdev/ On Dec 9, 2011, at 12:58 PM, Arnold Schwaighofer wrote: > >> As Jakob pointed out to me, the core problem is that the current >> register scavenger implementation will only give you one register; for >> the PowerPC case, and it looks like for your case as well, we might >> really need two registers. In the short term, a reasonable solution

With 1.9.37 the following script worked fine, with 1.9.39 it fails. Any idea what the issue is? Olaf ... mount -o /dev/vda1 /sysroot/ [ 1.396411] EXT4-fs (vda1): mounting ext2 file system using the ext4 subsystem [ 1.533090] EXT4-fs (vda1): mounted filesystem without journal. Opts: (null) guestfsd: main_loop: proc 1 (mount) took 0.45 seconds libguestfs: recv_from_daemon: 40 bytes: 20 00