This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC, PATCH][LRA, MIPS] ICE: in decompose_normal_address, at rtlanal.c:5817
- From: Jeff Law <law at redhat dot com>
- To: Robert Suchanek <Robert dot Suchanek at imgtec dot com>, Steven Bosscher <stevenb dot gcc at gmail dot com>, "vmakarov at redhat dot com" <vmakarov at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, rdsandiford at googlemail dot com
- Date: Mon, 12 Jan 2015 11:32:41 -0700
- Subject: Re: [RFC, PATCH][LRA, MIPS] ICE: in decompose_normal_address, at rtlanal.c:5817
- Authentication-results: sourceware.org; auth=none
- References: <B5E67142681B53468FAF6B7C31356562440589AC at hhmail02 dot hh dot imgtec dot org> <CABu31nPzNNhAOG6RE3pEu+REkNRu-kA9poQOGNJxeAqmBrRmZQ at mail dot gmail dot com> <B5E67142681B53468FAF6B7C3135656244116DFB at hhmail02 dot hh dot imgtec dot org> <54B00CAA dot 60207 at redhat dot com> <87h9vyg5n7 dot fsf at googlemail dot com>
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