Re: [PATCH] Fix DSE not to consider calls as reads from function's body (PR target/77834)

On 11/04/2016 05:35 PM, Jakub Jelinek wrote: 2016-11-04 Jakub Jelinek PR target/77834 * dse.c (dse_step5): Call scan_reads even if just insn_info->frame_read. Improve and fix dump file messages. Sounds reasonable, and I checked and it seems not

Re: [PATCH] Fix DSE not to consider calls as reads from function's body (PR target/77834)

On Fri, Nov 04, 2016 at 05:18:13PM +0100, Bernd Schmidt wrote: > On 11/04/2016 01:26 PM, Jakub Jelinek wrote: > > > >In any case, the second hunk fixes an important DSE bug that just got > >revealed by the former change. > > Can you elaborate on that (what situation does it occur in, is it

Re: [PATCH] Fix DSE not to consider calls as reads from function's body (PR target/77834)

On 11/04/2016 01:26 PM, Jakub Jelinek wrote: In any case, the second hunk fixes an important DSE bug that just got revealed by the former change. Can you elaborate on that (what situation does it occur in, is it covered by the testsuite)? Bernd

Re: [PATCH] Fix DSE not to consider calls as reads from function's body (PR target/77834)

On Fri, 4 Nov 2016, Jakub Jelinek wrote: > On Fri, Nov 04, 2016 at 01:59:05PM +0100, Richard Biener wrote: > > > So like the variant patch I've just posted? > > > > That doesn't handle > > > > int __attribute__((const,noinline)) > > foo () > > { > > return 1; > > } > > > > int bar() > > { >

Re: [PATCH] Fix DSE not to consider calls as reads from function's body (PR target/77834)

On Fri, Nov 04, 2016 at 01:59:05PM +0100, Richard Biener wrote: > > So like the variant patch I've just posted? > > That doesn't handle > > int __attribute__((const,noinline)) > foo () > { > return 1; > } > > int bar() > { > *((int *)foo) + 4 = 2; > int ret = foo (); > *((int *)foo) + 4

Re: [PATCH] Fix DSE not to consider calls as reads from function's body (PR target/77834)

On Fri, 4 Nov 2016, Jakub Jelinek wrote: > On Fri, Nov 04, 2016 at 01:47:36PM +0100, Richard Biener wrote: > > I'm not sure the current code handled this correctly? At least I > > see nothing on the GIMPLE level that would disallow the DSE: > > > > int foo () > > { > > char a[256]; > > a[0]

Re: [PATCH] Fix DSE not to consider calls as reads from function's body (PR target/77834)

On Fri, Nov 04, 2016 at 01:47:36PM +0100, Richard Biener wrote: > I'm not sure the current code handled this correctly? At least I > see nothing on the GIMPLE level that would disallow the DSE: > > int foo () > { > char a[256]; > a[0] = 'a'; > a[1] = 'b'; > int __attribute__((const))

Re: [PATCH] Fix DSE not to consider calls as reads from function's body (PR target/77834)

On Fri, Nov 04, 2016 at 01:33:54PM +0100, Bernd Schmidt wrote: > On 11/04/2016 01:26 PM, Jakub Jelinek wrote: > > > >The following patch avoids that. Of course the question is if we want > >to support something like: > >char var[64]; > >... > >var[0] = '0xe8'; > >var[1] = ...; > >(void (*fn)

Re: [PATCH] Fix DSE not to consider calls as reads from function's body (PR target/77834)

On Fri, 4 Nov 2016, Jakub Jelinek wrote: > Hi! > > One of the common reasons why nonoverlapping_memrefs_p is called with > MEM_EXPRs that are FUNCTION_DECLs and don't have DECL_RTL set is that > DSE considers all calls to be memory reads from what is being called. > > The following patch avoids

Re: [PATCH] Fix DSE not to consider calls as reads from function's body (PR target/77834)

On 11/04/2016 01:26 PM, Jakub Jelinek wrote: The following patch avoids that. Of course the question is if we want to support something like: char var[64]; ... var[0] = '0xe8'; var[1] = ...; (void (*fn) (void) = (void (*) (void)) [0]; fn (); without any kind of barrier, or not. I was going

[PATCH] Fix DSE not to consider calls as reads from function's body (PR target/77834)

Hi! One of the common reasons why nonoverlapping_memrefs_p is called with MEM_EXPRs that are FUNCTION_DECLs and don't have DECL_RTL set is that DSE considers all calls to be memory reads from what is being called. The following patch avoids that. Of course the question is if we want to support