Re: [PATCH][SPARC] PR target/80968 Prevent stack loads in return delay slot.

2017-06-12 Thread David Miller
From: Eric Botcazou Date: Mon, 12 Jun 2017 11:27:10 +0200 >> I do not see a direct gen_return happening in function.c in the gcc-7 >> branch. >> >> Is it somewhere else? > > There is a call from force_nonfallthru_and_redirect in cfgrtl.c AFAICS. > > So the code generated for your testcase is l

Re: [PATCH][SPARC] PR target/80968 Prevent stack loads in return delay slot.

2017-06-12 Thread Eric Botcazou
> I do not see a direct gen_return happening in function.c in the gcc-7 > branch. > > Is it somewhere else? There is a call from force_nonfallthru_and_redirect in cfgrtl.c AFAICS. So the code generated for your testcase is less optimized with GCC 7 and later than with GCC 6 and earlier? -- Er

Re: [PATCH][SPARC] PR target/80968 Prevent stack loads in return delay slot.

2017-06-10 Thread David Miller
From: Eric Botcazou Date: Fri, 09 Jun 2017 22:13:20 +0200 >> Eric, after some more testing it turns out that we need something >> more for gcc-5 and gcc-6 to cover all cases. > > Hmm, yes, I should have thought of that... > >> The problem is that before gcc-7, the compiler can emit return >> in

Re: [PATCH][SPARC] PR target/80968 Prevent stack loads in return delay slot.

2017-06-09 Thread Eric Botcazou
> Eric, after some more testing it turns out that we need something > more for gcc-5 and gcc-6 to cover all cases. Hmm, yes, I should have thought of that... > The problem is that before gcc-7, the compiler can emit return > instructions directly without going through the epilogue expander. That

Re: [PATCH][SPARC] PR target/80968 Prevent stack loads in return delay slot.

2017-06-09 Thread David Miller
From: David Miller Date: Tue, 06 Jun 2017 15:02:55 -0400 (EDT) > From: David Miller > Date: Mon, 05 Jun 2017 20:54:46 -0400 (EDT) > >> From: Eric Botcazou >> Date: Tue, 06 Jun 2017 00:02:06 +0200 >> That seems to work as well, following is going through a testsuite run right now: >>

Re: [PATCH][SPARC] PR target/80968 Prevent stack loads in return delay slot.

2017-06-06 Thread David Miller
From: David Miller Date: Mon, 05 Jun 2017 20:54:46 -0400 (EDT) > From: Eric Botcazou > Date: Tue, 06 Jun 2017 00:02:06 +0200 > >>> That seems to work as well, following is going through a testsuite >>> run right now: >>> >>> >>> [PATCH] sparc: Fix stack references in retur

Re: [PATCH][SPARC] PR target/80968 Prevent stack loads in return delay slot.

2017-06-05 Thread David Miller
From: Eric Botcazou Date: Tue, 06 Jun 2017 00:02:06 +0200 >> That seems to work as well, following is going through a testsuite >> run right now: >> >> >> [PATCH] sparc: Fix stack references in return delay slot. >> >> gcc/ >> >> PR target/80968 >> * config/sparc

Re: [PATCH][SPARC] PR target/80968 Prevent stack loads in return delay slot.

2017-06-05 Thread Eric Botcazou
> That seems to work as well, following is going through a testsuite > run right now: > > > [PATCH] sparc: Fix stack references in return delay slot. > > gcc/ > > PR target/80968 > * config/sparc/sparc.c (sparc_expand_prologue): Emit frame > blockage if fun

Re: [PATCH][SPARC] PR target/80968 Prevent stack loads in return delay slot.

2017-06-04 Thread David Miller
From: Eric Botcazou Date: Sun, 04 Jun 2017 10:32:47 +0200 >> This is an attempt to fix PR target/80968. This bug has existed >> basically forever. >> >> The stack_tie sequence seems to be how other targets deal with this >> issue. I only emit this when alloca is used. If there are other >> co

Re: [PATCH][SPARC] PR target/80968 Prevent stack loads in return delay slot.

2017-06-04 Thread Eric Botcazou
> This is an attempt to fix PR target/80968. This bug has existed > basically forever. > > The stack_tie sequence seems to be how other targets deal with this > issue. I only emit this when alloca is used. If there are other > conditions that potentially would necessitate such a barrier, just l