This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Short Displacement Problems.


> Zack Weinberg  wrote:
> > 
> > One problem with this strategy is that
> > reshuffling stack during reload is expensive because
> > 
> > 1. There would be lot of stack variable references that we 
> will have to
> >    fix up in insn chain while allocating  "each" stack slot.
> >    The entire logic will increase compilation  time.
> 
> Only if we stick with the existing, lame, way of representing stack
> slots.  (mem:MODE (plus:P (reg:P sp) (const_int offset))) is a pain to
> work with, yes.  Consider (stack:MODE slot) instead -- with slot being
> akin to a pseudo-register number, and only one instance of any given
> stack RTX.  We could assign memory locations to these with just one
> linear scan over the RTL to replace them with MEM expressions at the
> end.

I agree with you on this.The present stack representation is a
bottleneck and possibly if we decide a better one, it would 
beneficial in the long run.
 
> In fact, if we used this representation from RTL creation time all the
> way to after register allocation, we could make some significant
> improvements to code generation, independent of the
> stack-slot-assignment issue.
> 
> Yeah, this would require changes to every machine description and
> every RTL optimizer pass, but it would be worth it.

To minimize changes, I  am thinking of abstracting the stack 
in a slightly different way.
Initially we take the ASSUMPTION that all pseudos would be on to the stack
and pseudos would be placed on the "big virtual stack" based on locality.  
So stack assignment of all psuedos on "virtual stack" is complete before
register
allocation had begun.The reload pass would get rtx's from this
virtual stack.
But finally, all pseudos would not go onto stack.In a post register
allocation pass
this virtual stack is "collapsed" to an actual realistic stack.

Initially, I am thinking to enable this virtual stack for SH only and other
ports might go on to it once I am able to set up a complete infrastructure
in place.

Please let me know if that looks promising enough.

Best Regards,
  Naveen Sharma.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]