search for: foldmemoryoperand

...("Missing mayLoad flag", MI); if (Op->isStore() && !MI->mayStore()) report("Missing mayStore flag", MI); } The MI is ARM::tBL, and it doesn't have mayLoad set, which hits the assert in MachineVerifier, since it still has memory operands attached by foldMemoryOperand. I have attached patch (changes to foldMemoryOperand), that checks if the MI returned by foldMemoryOperandImpl has mayLoad or mayLoadOrStore property set, and then proceed with adding memory operands, which seems to resolve the issue. Testing with make check-llvm with enable expensive checks doesn&...

Hi, While working on https://reviews.llvm.org/D79785, we wanted to define foldMemoryOperandImpl hook for Thumb1, that folds load, indirect call to direct call tLDRpci, tBLX -> tBL. This triggered an assertion error with expensive checks turned on in MachineVerifier because the newly created tBL insn by Thumb1InstrInfo::foldMemoryOperandImpl had memory operands of LoadMI attached by Ta...

I think I'm getting a bit closer to the problem. I've found that the call to InlineSpiller::foldMemoryOperand() inside InlineSpiller::spillAroundUses() is causing the problems. As a test, I removed that call and with your yesterday's patch I'm not getting any errors at all, the code generated is the same one as with the call. This is happening when InlineSpiller::foldMemoryOperand() returns true, s...

On Jul 15, 2012, at 4:50 PM, Borja Ferrer <borja.ferav at gmail.com> wrote: > I think I'm getting a bit closer to the problem. I've found that the call to InlineSpiller::foldMemoryOperand() inside InlineSpiller::spillAroundUses() is causing the problems. > As a test, I removed that call and with your yesterday's patch I'm not getting any errors at all, the code generated is the same one as with the call. This is happening when InlineSpiller::foldMemoryOperand() returns t...

On Jul 15, 2012, at 9:20 AM, Borja Ferrer <borja.ferav at gmail.com> wrote: > Jakob, one more hint, I've placed some asserts around the code you added and noticed that the InlineSpiller::insertReload() function is not being called. > > 2012/7/14 Borja Ferrer <borja.ferav at gmail.com> > Hello Jakob, > > I'm still getting the error, I can give you any other

...April 2020 01:44 > To: John Brawn <John.Brawn at arm.com> > Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] [ARM] Register pressure with -mthumb forces register reload before each call > > Hi, > I have attached WIP patch for adding foldMemoryOperand to Thumb1InstrInfo. > For the following case: > > void f(int x, int y, int z) > { > void bar(int, int, int); > > bar(x, y, z); > bar(x, z, y); > bar(y, x, z); > bar(y, y, x); > } > > it calls foldMemoryOperand twice, and thus converts two calls from...

...const TargetMachine & target_machine = this->machine_function->getTarget(); const MRegisterInfo *ri = target_machine.getRegisterInfo(); MachineInstr * fmi = ri->foldMemoryOperand(mi, u, slot); if(fmi) { numFolded++; MachineBasicBlock * mbb = mi->getParent(); ------> //this->vrm->virtFolded(v_reg, mi, u, fmi); ks.fold_inst(mi, fmi); // TODO: see if it is not necessary to iterate...

...evidently wrong, I would > appreciate if someone tells me. With the comment on vrm->virtFolded, I am > passing all the tests that I have. I haven't had a chance to look at the code you have below, but I would guess that you are leaving a dangling pointer in some map somewhere. "foldMemoryOperand", if successful, leaves the original instruction in the program. When you delete this instruction (which is require to avoid miscompiling the program) you must inform virtregmap that you've done this, by calling 'virtFolded'. This is important, because it allows the virtregma...

...ix. Could someone tell me which steps should I take in order to correctly fold memory operands? The code that I am using is: const TargetMachine & target_machine = this->machine_function->getTarget(); const MRegisterInfo *ri = target_machine.getRegisterInfo(); MachineInstr * fmi = ri->foldMemoryOperand(mi, u, slot); if(fmi) { numFolded++; MachineBasicBlock * mbb = mi->getParent(); this->vrm->virtFolded(v_reg, mi, u, fmi); //std::cerr << "Folding " << NeatPrint::mi2string(*mi, *this->machine_function) << "\n"; // TODO: see if it is n...

...on - Reverse engineered the CALLSEQ_* series of nodes to insert my node after the CALL node in both glue and chain sequences. (BTW, is there any documentation on the call sequence? I think I've reverse engineered it correctly, but I'm not completely sure.) - Introduced folding logic in foldMemoryOperand (analogous to PATCHPOINT, but which marks both load and store) -- this is where my problem currently lies - Inserted code during MCInstLower to record the statepoint The problem with this is that a reload from a stack slot will sometimes be inserted between the CALL and the SAFEPOINT. This is...

...uld I > take > in order > to correctly fold memory operands? The code that I am using is: > > const TargetMachine & target_machine = > this->machine_function->getTarget(); > const MRegisterInfo *ri = target_machine.getRegisterInfo(); > MachineInstr * fmi = ri->foldMemoryOperand(mi, u, slot); > if(fmi) { > numFolded++; > MachineBasicBlock * mbb = mi->getParent(); > this->vrm->virtFolded(v_reg, mi, u, fmi); > //std::cerr << "Folding " << NeatPrint::mi2string(*mi, > *this->machine_function) << "\n&quo...

...existing back-ends) using this approach. That's right. What you are doing is very different from what a 'real' target requires, so you should probably try to figure out which passes make sense for a GPU back-end. > For the stack slot approach, what exactly are the semantics of the foldMemoryOperandImpl method? And how does it relate to the storeRegToStackSlot and readRegFromStackSlot methods? Do the storeReg/readReg methods generate the (load/store) spill code and the foldMemoryOperandImpl method combine the generated loads/stores directly into the instructions that reference them? When a...

Hi, I have attached WIP patch for adding foldMemoryOperand to Thumb1InstrInfo. For the following case: void f(int x, int y, int z) { void bar(int, int, int); bar(x, y, z); bar(x, z, y); bar(y, x, z); bar(y, y, x); } it calls foldMemoryOperand twice, and thus converts two calls from blx to bl. callMI->dump() shows the function name "bar...

...ially redundant) places. >>> >>> That makes sense to me, but note that this is not currently implemented. All our RISC-like targets only support folding of COPY to load/store through the target-independent mechanisms. >>> >>> It should be fairly simple to add a foldMemoryOperandImpl override to ARM that folds load+zext into a zextload. >> >> Really? I'm pretty sure that ppc folded load into [sz]ext (with custom code). If ARM isn't doing this, it should - it is a clear win. > > It is entirely possible I broke it when I added the COPY instructio...

...61318 So, mi2iMap_ seems to be indexes with an address of a spill instruction, which is not present in that map. I see that the map is originally initialized with instructions in function and then only modified at LiveIntervalAnalysis.cpp:219, but that code is only executed when MRegisterInfo::foldMemoryOperand returns something, and I did not define that method for my backend. Any ideas how I can debug this? I attach the dumps of machine code which cause the problems, but I'm afraid that won't be enough to reproduce the problem. Thanks in advance, Volodya -------------- next part ---------...

...nt (and non-partially redundant) places. >> >> That makes sense to me, but note that this is not currently implemented. All our RISC-like targets only support folding of COPY to load/store through the target-independent mechanisms. >> >> It should be fairly simple to add a foldMemoryOperandImpl override to ARM that folds load+zext into a zextload. > > Really? I'm pretty sure that ppc folded load into [sz]ext (with custom code). If ARM isn't doing this, it should - it is a clear win. It is entirely possible I broke it when I added the COPY instruction. I deleted the...

...function arguments (e.g. if we have enough live local variables). For the second, looking at InlineSpiller.cpp it does have the concept of rematerializing by folding a memory operand into another instruction, so I think we could make use of that to do this. It looks like it would involve adding a foldMemoryOperand function to ARMInstrInfo and then have this fold a LDR into a BX by turning it into a BL. John ________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Prathamesh Kulkarni via llvm-dev <llvm-dev at lists.llvm.org> Sent: 07 April 2020 21:07 To:...

...cal register definitions still needed? This would seem to defeat the purpose of using virtual registers in the first place. Unfortunately, there do not seem to be any documentation (or even existing back-ends) using this approach. For the stack slot approach, what exactly are the semantics of the foldMemoryOperandImpl method? And how does it relate to the storeRegToStackSlot and readRegFromStackSlot methods? Do the storeReg/readReg methods generate the (load/store) spill code and the foldMemoryOperandImpl method combine the generated loads/stores directly into the instructions that reference them? >...

On May 17, 2011, at 11:32 AM, Andrew Clinton wrote: > On 05/17/2011 12:54 PM, Jakob Stoklund Olesen wrote: >> What you can do instead is: >> >> 1) Just use virtual registers and skip register allocation, or >> >> 2) Allocate to a small register file, implement memory operand folding, and pretend that spill slots are registers. >> >> /jakob >>

> On Jun 28, 2017, at 5:10 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Oh wait, vreg1 is indeed used. > Yeah, having a dead flag here sounds wrong. I mean on the instruction itself. On the bundle, that’s debatable. That would fit the semantic “if no side effect you can kill it” (here there is side effect, we define other vregs). > >> On