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)

On Mon, Feb 1, 2016 at 1:51 PM, Bernd Schmidt wrote: > On 02/01/2016 01:49 PM, Richard Biener wrote: > >> What prevents motion of those across a stack adjustment (thus a place >> they are _not_ valid?) > > > If the address is SP-based, dependencies on the address register. If

AW: 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)

Hi, On 02/01/2016 13:18, Bernd Schmidt wrote: > On 01/29/2016 08:42 PM, Bernd Edlinger wrote: > > 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

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)

On 01/29/2016 08:42 PM, Bernd Edlinger wrote: On 29.01.2016 16:47 Bernd Schmidt wrote: 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.

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)

On Mon, Feb 1, 2016 at 1:18 PM, Bernd Schmidt wrote: > On 01/29/2016 08:42 PM, Bernd Edlinger wrote: >> >> On 29.01.2016 16:47 Bernd Schmidt wrote: >>> >>> >>> Yes. What is the problem with that? If we have (plus sfp const_int) at >>> any point before reload, we can check

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)

On 02/01/2016 01:49 PM, Richard Biener wrote: What prevents motion of those across a stack adjustment (thus a place they are _not_ valid?) If the address is SP-based, dependencies on the address register. If you're thinking prologue stack adjustments, ports where this could be an issue emit

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)

On 29.01.2016 02:09, Bernd Schmidt wrote: > On 01/28/2016 12:36 AM, Eric Botcazou wrote: >>> [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: >>> >>> [...]

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)

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

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)

On Fri, Jan 29, 2016 at 02:09:25AM +0100, Bernd Schmidt wrote: > I'm on the fence; I do think the original problem is an issue we should fix, > but I'm also not terribly happy with the implementation we have right now. The fact that it has been only reported from generated testcases only means we

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)

On 28.01.2016 23:17, Richard Sandiford wrote: > Bernd Edlinger writes: >> On 26.01.2016 22:18, Richard Sandiford wrote: >>> [cc-ing Eric as RTL maintainer] >>> >>> Matthew Fortune writes: Bernd Edlinger

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)

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

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)

Bernd Edlinger writes: > On 26.01.2016 22:18, Richard Sandiford wrote: >> [cc-ing Eric as RTL maintainer] >> >> Matthew Fortune writes: >>> Bernd Edlinger writes: Matthew Fortune

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)

On 01/28/2016 12:36 AM, Eric Botcazou wrote: [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

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)

> [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

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)

On 26.01.2016 22:18, Richard Sandiford wrote: > [cc-ing Eric as RTL maintainer] > > Matthew Fortune writes: >> Bernd Edlinger writes: >>> Matthew Fortune writes: Has the patch been tested beyond just

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)

[cc-ing Eric as RTL maintainer] Matthew Fortune writes: > Bernd Edlinger writes: >> Matthew Fortune writes: >> > Has the patch been tested beyond just building GCC? I can do a >> > test run for you if you don't