Bernd Edlinger writes:
> this patch skips the redundant re-computing of the frame info after reload
> completed.
>
> I looked at all available targets initial_elimination_offset functions:
>
> All of them currently use either a trivial function of
> crtl->outgoing_args_size,
> get_frame_size (
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 have things set up to do one yourself.
>
> I built a cross-gcc with all languages and a cross-glibc, but I have
> not set up an emulation environm
[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 have things set up to do one yourself.
>>
>> I built a cross-gcc with all languages
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 building GCC? I can do a
test run for you if you don't have things set up to do one yo
> [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 cal
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 writes:
> Has the patch been tested beyond just building GCC? I can do a
> test run for you if you don'
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 INITIAL_ELIMINATION_OFFSE
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:
>>>
>>> [...]
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
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
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 writes:
> Matthew Fortune writes:
>> Has the patch been tested beyond just buil
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 consi
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.
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 whether that offset is in
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
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 you're
> thinking pro
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 x==1234
17 matches
Mail list logo