search for: fprel

...emOperands instead? In theory, > they should already be preserving the needed information. If > they're not sufficient, could they be improved? Yeah, I'm not totally happy with that mapping either. With MachineMemOperands, would that be the getOffset() method? That's only for FPRel data, though. What if frame pointer elimination has been run? I would love to get out from under the map if possible. > There is work going on to improve the register allocator's ability > to use rematerlialization. In a world where the register allocator > can aggressively remat m...

...fixed frame object, so it's independent of whether frame pointer > elimination has been done, and it's independent of the actual frame > offsets. >From MachineMemOperand.h: /// getValue - Return the base address of the memory access. /// Special values are PseudoSourceValue::FPRel, PseudoSourceValue::SPRel, /// and the other PseudoSourceValue members which indicate references to /// frame/stack pointer relative references and other special references. const Value *getValue() const { return V; } I don't see PseudoSourceValue::FPRel, etc. defined anywhere. How do I...

...should already be preserving the needed information. If >> >> they're not sufficient, could they be improved? >> > > Yeah, I'm not totally happy with that mapping either. With > MachineMemOperands, would that be the getOffset() method? That's > only for FPRel data, though. What if frame pointer elimination has > been run? > > I would love to get out from under the map if possible. MachineMemOperands for spill slots use FixedStack PseudoSourceValues as their base. There's a unique FixedStack PseudoSourceValue for each fixed frame object, s...

...y, > > they should already be preserving the needed information. If > > they're not sufficient, could they be improved? > > Yeah, I'm not totally happy with that mapping either. With > MachineMemOperands, would that be the getOffset() method? That's > only for FPRel data, though. What if frame pointer elimination has > been run? > > I would love to get out from under the map if possible. Are MachineMemOperands available at AsmPrinter time? Where are they stashed? -Dave

On Monday 14 September 2009 15:28, David Greene wrote: > I don't see PseudoSourceValue::FPRel, etc. defined anywhere. How do I know > if a PseudoSourceValue is from the stack? Ok, the comment is misleading. I see the class defined in PseudoSourceValue.cpp now. I'll move it to the header. I have another question. Looking at the list of MachineMemOperands for an instruction, is...

...If >>> >>> they're not sufficient, could they be improved? >>> >> >> >> Yeah, I'm not totally happy with that mapping either. With >> >> MachineMemOperands, would that be the getOffset() method? That's >> >> only for FPRel data, though. What if frame pointer elimination has >> >> been run? >> >> >> >> I would love to get out from under the map if possible. >> > > Are MachineMemOperands available at AsmPrinter time? Where are they > stashed? Yes. There are some p...

Hi Dave, On Sep 11, 2009, at 3:31 PM, David Greene wrote: > Attached is a patch to print asm comments for spill information. > We've discussed the mechanisms before but I wanted to run the > patch by everyone before I start to commit pieces. The Offset->FrameIndex mapping seems rather heavy-weight, as any expense is incurred even when AsmVerbose is off. Would it be possible to

Attached is a patch to print asm comments for spill information. We've discussed the mechanisms before but I wanted to run the patch by everyone before I start to commit pieces. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: spillcomments.patch Type: text/x-diff Size: 58930 bytes Desc: not available URL: