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

[Richard Biener]

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()
> > {
> >   *((int *)foo) + 4 = 2;
> >   int ret = foo ();
> >   *((int *)foo) + 4 = 1;
> >   return ret;
> > }
> > 
> > right?  patching foo to return 2, calling foo and then unpatching it?
> 
> If you mean *((int *)foo + 4) = rather than *((int *)foo) + 4,
> then indeed it doesn't.  But GIMPLE optimizers remove that far before.
> And I'm not sure if we want to pessimize code just for such hypothetical
> cases; users can always add explicit optimization barriers;
> or maybe just have a flag whether function text is writable
> and disable that flag by default on non-bare metal?
> Unless the function is in a writable section, if it isn't the kernel
> or embedded target, most likely the function body won't be writable anyway.

Not sure if it will pessimize much, but yes, if we want to support it
there's the complication that the const call has no VOPs on GIMPLE
and I'm not sure we want to force VUSEs on all const calls...

> Note I'm not sure that even without the patch we'd handle it at the
> DSE/sched time - the thing is that the call's argument is a mem:QI,
> so effectively represents just the first byte of the function.  So
> if you stored to the first byte of the function, it might handle it
> "right", but if you store 4 bytes at offset 4, nonoverlapping_memrefs_p
> might still figure out that it is comparing a offset 4 4 byte memory
> with offset 0 1 byte memory and tell they don't overlap.

Yeah, but I hope MEM_SIZE_KNOWN_P is false for the MEM, that should
do the trick (at least that's what I remember - I'm not that fluent
with RTL).

Richard.