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]
Other format: [Raw text]

Re: [RFC, PATCH][LRA, MIPS] ICE: in decompose_normal_address, at rtlanal.c:5817


On 01/10/15 05:51, Richard Sandiford wrote:

I agree this is the kind of thing we'd need to consider if we were
deciding whether it's valid to connect a (lo_sum (high x+N) x+N) to an
existing (high x).  But this code is handling cases where the connection
has already been made and we're trying to simplify the result.  Would it
be valid RTL to use:
And I probably should have said that if we've already somehow determined that the high/losum are paired then it'd be OK. I hesitated simply because I hadn't walked how this code was called or used in any detail.


   (lo_sum (high x) (const (plus x offset)))

to mean anything other than x+offset?
Agreed, when we've made a connection between the two -- for example, if we know the output of the high dominates and was originally used in the lo_sum. However, we can't make that assumption for an arbitrary high/lo_sum, even if they refer to the same x.


If we do go for the change, I think we should generalise it to handle
(lo_sum (high x+N) x+N') and (lo_sum (high x-N) x) too.  Things like
get_related_value or split_const could help there.
Unless the change is pretty trivial, this might be a gcc-6 kind of thing.

jeff


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