Patch for offsettable_address_p to handle LO_SUM
Sun Jan 31 15:21:00 GMT 1999
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
> > 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
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
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
I think having these macros would help folks to think about these
issues. They also help to describe the target machine and provide
> 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 :-)
More information about the Gcc-patches