This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Is it OK for rtx_addr_can_trap_p_1 to attempt to compute the frame layout? (was Re: [PATCH] Skip re-computing the mips frame info after reload completed)
- From: Eric Botcazou <ebotcazou at libertysurf dot fr>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Matthew Fortune <Matthew dot Fortune at imgtec dot com>, Bernd Edlinger <bernd dot edlinger at hotmail dot de>, Nick Clifton <nickc at redhat dot com>
- Date: Thu, 28 Jan 2016 00:36:36 +0100
- Subject: Re: Is it OK for rtx_addr_can_trap_p_1 to attempt to compute the frame layout? (was Re: [PATCH] Skip re-computing the mips frame info after reload completed)
- Authentication-results: sourceware.org; auth=none
- References: <HE1PR07MB09054A3F1F796882634605CEE4C50 at HE1PR07MB0905 dot eurprd07 dot prod dot outlook dot com> <6D39441BF12EF246A7ABCE6654B023536A705EB0 at LEMAIL01 dot le dot imgtec dot org> <87y4bcavl5 dot fsf_-_ at googlemail dot com>
> [cc-ing Eric as RTL maintainer]
Sorry for the delay, the message apparently bounced]
> IMO the problem is that rtx_addr_can_trap_p_1 duplicates a large
> bit of LRA/reload logic:
>
> [...]
>
> Under the current interface macros like INITIAL_ELIMINATION_OFFSET
> are expected to trigger the calculation of the target's frame layout
> (since you need that information to answer the question).
> To me it seems wrong that we're attempting to call that sort of
> macro in a query routine like rtx_addr_can_trap_p_1.
I'm a little uncomfortable stepping in here because, while I essentially share
your objections and was opposed to the patch (I was almost sure that it would
introduce maintainance issues for no practical benefit), I didn't imagine that
such a failure mode would have been possible (computing an approximation of
the frame layout after reload being problematic) so I didn't really object to
being overruled after seeing Bernd's patch...
> IMO we should cache the information we need@the start of each
> LRA/reload cycle. This will be more robust, because there will
> be no accidental changes to global state either during or after
> LRA/reload. It will also be more efficient because
> rtx_addr_can_trap_p_1 can read the cached variables rather
> than calling back into the target.
That would be a better design for sure and would eliminate the maintainance
issues I was originally afraid of.
My recommendation would be to back out Bernd's patch for GCC 6.0 (again, it
doesn't fix any regression and, more importantly, any bug in real software,
but only corner case bugs in dumb computer-generated testcases) but with the
commitment to address the underlying issue for GCC 7.0 and backport the fix to
GCC 6.x unless really impracticable. That being said, it's ultimately Jakub
and Richard's call.
--
Eric Botcazou