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: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Bernd Schmidt <bschmidt at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>
- Cc: Eric Botcazou <ebotcazou at libertysurf dot fr>, Richard Sandiford <rdsandiford at googlemail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Matthew Fortune <Matthew dot Fortune at imgtec dot com>, "Nick Clifton" <nickc at redhat dot com>
- Date: Fri, 29 Jan 2016 19:42:41 +0000
- 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
- Authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=hotmail.de;
- 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> <1634352 dot Ak3Qm2WKut at polaris> <56AABBC5 dot 6090309 at redhat dot com> <20160129154141 dot GS3017 at tucnak dot redhat dot com> <56AB8989 dot 5050705 at redhat dot com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
On 29.01.2016 16:47 Bernd Schmidt wrote:
> On 01/29/2016 04:41 PM, Jakub Jelinek wrote:
>> On Fri, Jan 29, 2016 at 02:09:25AM +0100, Bernd Schmidt wrote:
>
>>> I think a better approach might be to just mark accesses at known
>>> locations
>>> in the frame, or arg pushes, as MEM_NOTRAP_P, and consider accesses with
>>> non-constant or calculated offsets as potentially trapping.
>>
>> I don't see how that would work generally. Sure, if there is e.g. a
>> constant
>> offset array access, it could be checked easily, but if there is
>> variable offset
>> array access, that is at some point later on changed into a constant
>> offset
>> access, you'd need to be conservative, unless you can prove it is in
>> range.
>
> Yes. What is the problem with that? If we have (plus sfp const_int) at
> any point before reload, we can check whether that offset is inside
> frame_size. If it isn't or if the offset isn't known, it could trap.
>
>
Usually we have "if (x==1234) { read MEM[FP+x]; }", so wo don't know,
and then after reload: "if (x==1234) { read MEM[SP+x+sp_fp_offset]; }"
but wait, in the if statement we know, that x==1234, so everything
turns in one magic constant, and we have a totally new constant offset
from the SP register "if (x==1234) { read MEM[SP+1234+sp_fp_offset]; }".
Now if rtx_addr_can_trap_p(MEM[SP+1234+sp_fp_offset]) says it cannot
trap we think we do not need the if at all => BANG.
Bernd.