[llvm-commits] [llvm] r111850 - /llvm/trunk/lib/Target/ARM/ARMFastISel.cpp

[Eric Christopher]

> 
> I was going to ask, "Is there a check somewhere to make sure we don't try to get here in Thumb or Thumb2 mode?" but you've already checked in exactly that. So moving on... 
> 

:)

> getFrameIndexReference() doesn't check whether the reg/offset will be in range for an instruction, but rather just returns the appropriate base register and the offset from it for a frame index reference. The LDR instruction generated here may thus have an out-of-range offset in the case of large (> 4k) stack frames. At least for now, it may be reasonable to just punt for offsets that don't fit in the immediate.
> 

Current in development patch :)

> Similarly, is there are check above this to make sure we're only dealing with GPR register class loads? Even in ARM mode, there's a number of others (see loadRegFromStackSlot() in ARMBaseInstrInfo.cpp for examples) that may need to be handled. Like the above, though, it's not unreasonable to just detect them and punt for now.

Not yet.  I think that's Now+1 in my plans.

> 
> You're resolving frame index references directly. Is this happening after register allocation? I don't see how it can be, but could be wrong. If it's pre-regalloc, those offsets will be incorrect, as the code won't know how many callee-saved register slots are allocated for the function, nor how many spill slots. Perhaps you can use loadRegFromStackSlot() and storeRegToStackSlot() directly and the use the normal PEI code?

I've worried about this, but it seems to work for X86 and it would have the same problems of spill code so I'm not worrying about it overly at the moment.  I don't promise any of this will work at the moment past not segfaulting :)

-eric