Re: Patch for offsettable_address_p to handle LO_SUM

[Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>]

Jeffrey A Law writes:
 > I don't really see the need for a new function to do this.  The test is 
 > trivial enough.

I agree.  However, the intention was to have a function that CSE could
call.

 >   > I doubt that this function will get called for most targets.  The only
 >   > one that should is the PA.
 > More correctly "will do anything useful" :-)  The function could get called
 > for any target which allowed LO_SUM addresses in memrefs.  Which is
 > several.

If any target other than the PA currently calls this function, there
is something wrong.  If they do, I imagine they have special code to
reject offsetting a LO_SUM address or they emit another insn to reload
the HIGH part.

 >   > +   return offset >= -LO_SUM_OFFSET_MAX && offset <= LO_SUM_OFFSET_MAX;
 >   > + }
 > Is this really safe?  Consider a (lo_sum (plus (symbol_ref) (LO_SUM_OFFSET_MAX))
 > 
 > We can't add anything to that since it'a already at the maximal
 > offset.  

Right.  I wondered about this and then forgot to fix it!

 > Seems to me you have to peek inside the LO_SUM, add the constants,
 > then look at LO_SUM_MAX_OFFSET.

No.  We've already emitted a HIGH/LO_SUM pair and are trying to decide
if we can safely emit another LO_SUM with some offset without having
to reload the HIGH part.

 > I also worry about the same problem at the other end.  We could have a
 > (lo_sum (plus (symbol_ref) (-LO_SUM_OFFSET_MAX - 1))
 > 
 > That's not offsettable either.

But if we have just emitted a (high (plus (symbol_ref)
(-LO_SUM_OFFSET_MAX - 1)) it should be OK.

 > I'm also a little concerned that someone would define those macros, but not be
 > aware of the assembler/linker issues for rounding HIGH.  If we continue with
 > this code we probably should add a comment about this in the
 > documentation.

I think having these macros would help folks to think about these
issues.  They also help to describe the target machine and provide
useful documentation.

 > Given that the PA port handles most of this kind of stuff early and doesn't
 > depend that much on offsettable memory references I wouldn't lose any sleep
 > if we just rejected LO_SUMs as not offsettable.

That is the simplest and most pragmatic solution.  It would solve my
immediate problem and save me some effort :-)

Michael.