search for: foldmemoryoperandimpl

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 Target...

...t("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't show unexpected failures. Do the changes to foldMemoryOperand look OK ? Thanks, Prathamesh On Wed, 9 Se...

Hi, I wonder if it would be possible to extend foldMemoryOperandImp() so that targets can check for liveness of a particular phys reg? The case I am thinking of is when the new instruction clobbers the CC reg, while the old one did not. In this case the new instruction can only become a replacement if the CC reg is known to be dead. The idea is that liveness of phys regs should be available

...und a reference to LiveIntervalAnalysis*. Patches welcome :) - Matthias > On Apr 27, 2016, at 11:38 AM, Jonas Paulsson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ping. > > Either this can be implemented easily, or the current SystemZ optimization LAY -> AGSI in foldMemoryOperandImpl() should be removed, since this is actually illegal. > > /Jonas > > On 2016-04-15 12:53, Jonas Paulsson wrote: >> Hi, >> >> I wonder if it would be possible to extend foldMemoryOperandImp() so that targets can check for liveness of a particular phys reg? >> &...

...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 RISC...

...ries to put the zexts in non-redundant (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. /jakob

...ondition operands, which must be done. The first check for this is to know if the CC register is live into any successor block. I know there has been corrupt live-in lists in the past found, but I think that was some passes after register allocation. Would it be safe to rely on live-in lists in foldMemoryOperandImpl()? Thanks, Jonas

...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? > /ja...

...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 regi...

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

...s in non-redundant (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. -Chris

...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 instruction. &...

...d we didn't even know for which instructions these spills are reloads are happening. All these APIs get is a frameIndex. > Now that you have decided to get us to explore a better path, it would be good if you could put more light to these issues. The main API hooks here are TargetInstrInfo::foldMemoryOperandImpl; there's a FrameIndex form and a generic load form. To be sure, I don't know if this kind of approach will work well. But if it does, it could help make PIC16 less different from other targets in LLVM. > > One more thing that I feel will simplify things in a great sense is to make...

...he test file above, in @testSum, switch %a, %b to %b, %a. llc will assert in Register Spilling: "Remaining use wasn't a snippet copy". Debug output shows STRabs being generated, followed by an attempted fold of a stack-load into ADDabs. I must be on the wrong track in M6502InstrInfo::foldMemoryOperandImpl. If someone could please explain this error, it would really help. Thanks! - Nolan

Dan Gohman wrote: > Have you ever investigated the following approach? Define fake > register+register forms of common instructions, in addition to the > register+memory forms. Let the instruction selector work as if > everything were in registers. Then, since there's only one physical > register, the register allocator will have to spill, and the spills > and reloads can

...is: - Provide a realistic number of physical registers. Make it similar to the target architecture, but aim low. - Map spill slots to PTX registers. That means 'spilling' is really a noop, except you get live range splitting and remat. If you implement TII::canFoldMemoryOperand() and TII::foldMemoryOperandImpl(), there will be no inserted loads and stores. The result should be code that is easy to register allocate for ptxas with some live ranges that obviously should go in registers, and some that obviously should spill. There will be a number of live ranges that can go either way, depending on the act...

On Aug 18, 2010, at 9:22 AM, Bob Wilson wrote: > I'm looking at llvm-generated ARM code that has some unnecessary UXTB (zero extend) instructions, and it seems to me that doing type legalization as an entirely local transformation is not the best approach. That's true, but doing isel as a purely local approach isn't the best either :-). We'd really like to get to

I'm looking at llvm-generated ARM code that has some unnecessary UXTB (zero extend) instructions, and it seems to me that doing type legalization as an entirely local transformation is not the best approach. I'm thinking in particular about legalizing integer types that need to be promoted to the target register size, i.e., i8 and i16 for ARM promoting to i32. Currently we sign-extend or

Currently, the TableGen register info files for all of the back-ends define concrete registers and divide them into logical register classes. I would like to get some input from the LLVM experts around here on how best to map this model to an architecture that does *not* have a concrete, pre-defined register file. The architecture is PTX, which is more of an intermediate form than a final

I've mentioned my sneaky plans to target the MOS6502 here before. The big issue I think is that a lot of instructions don't really have a choice for output register. It all just goes into the accumulator, X index, or Y index based on the specific instruction. So, my question is, when I'm defining my ins, outs and registers for these instructions, is it going to be a problem that