On 8/2/19 12:15 PM, Eric Botcazou wrote:
>> Yes, I've just verified that. Do you have access to the SPEC benchmark?
>
> Nope.
>
>> First big change is in before/exchange2.fppized.f90.130t.pre
>
> Is that at -Os? If not, then this isn't necessarily a problem. It looks
> like
> PRE is able to
> Yes, I've just verified that. Do you have access to the SPEC benchmark?
Nope.
> First big change is in before/exchange2.fppized.f90.130t.pre
Is that at -Os? If not, then this isn't necessarily a problem. It looks like
PRE is able to PRE-ify more stores, very likely because they no longer tr
> Note that the revision caused size increase of 548.exchange2_r SPEC 2017
> benchmark:
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=35.398.4
Are you sure? This should only change anything for nested functions.
--
Eric Botcazou
On 7/24/19 11:14 AM, Eric Botcazou wrote:
> Hi,
>
> stack memory is considered non-trapping by the compiler once the frame has
> been established so TREE_THIS_NOTRAP can be set on the dereferences built
> during the unnesting pass.
>
> Tested on x86_64-suse-linux, OK for the mainline?
>
>
> 2
On Wed, Jul 24, 2019 at 11:14 AM Eric Botcazou wrote:
>
> Hi,
>
> stack memory is considered non-trapping by the compiler once the frame has
> been established so TREE_THIS_NOTRAP can be set on the dereferences built
> during the unnesting pass.
>
> Tested on x86_64-suse-linux, OK for the mainline
