This is the mail archive of the gcc-patches@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]

Re: Adding constants to LO_SUM


    So this is partly a question about the alignment of "foo".

Right.  And that's what the lack of clarity in the documentation is.

    That is not the only factor.  Suppose that we know "foo" is aligned to
    a 64k boundary.  We still can't do this if N was 0xFFFF but there are
    only 12 bits added by low_sum.  So in addition to knowing about
    alignment, there is a maximum value that can be added for any
    particular target.

Correct.  I made it the size of the mode of the memref, which is consistent
with what adj_offsettable_memref did.

As far as I can see the only time this will fail is if we have a target which
has LO_SUM but not STRICT_ALIGNMENT.  I don't think there are any such,
though I agree that this is an assumption that ought to be stated someplace.

    I don't think it's quite the same as the old behaviour.  It used to be
    that only a very few places would try to do this, and some of them had
    comments explaining why the author thought it would be safe.  Are the
    places that your patch affects really the same places as the places
    that used to do this?

I saw absolutely no such comments or I would have thought about this
issue earlier.  It is true that this used to only happen on calls to
adj_offsettable_address while now it occurs more often.

    Perhaps you could have a target macro that describes this more
    precisely?  It is actually a new optimisation, because presumably
    before the code would have been changed into

    (set (reg 3) (high (plus (symbol_ref "foo") (const_int N))))
    (set (reg 4) (lo_sum (reg 3) (plus (symbol_ref "foo") (const_int N))))

    which is always safe (assuming it's a valid address), but will not CSE
    as well.

Right.  Another thing we need to do someplace is have code that knows to
adjust *both* the HIGH and LO_SUM, but that's a whole different story.


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