On Thu, May 3, 2012 at 11:38 AM, David Miller <da...@davemloft.net> wrote: > From: Richard Sandiford <rdsandif...@googlemail.com> > Date: Thu, 03 May 2012 10:17:44 +0100 > >> Richard Guenther <richard.guent...@gmail.com> writes: >>> On Thu, May 3, 2012 at 10:31 AM, Richard Sandiford >>> <rdsandif...@googlemail.com> wrote: >>>> David Miller <da...@davemloft.net> writes: >>>>> From: Richard Sandiford <rdsandif...@googlemail.com> >>>>> Date: Wed, 02 May 2012 20:37:58 +0100 >>>>> >>>>>> I think the DSE assuption is fair though. If you reuse MEMs like >>>>>> this, then they're no longer just serving the purpose described by >>>>>> MEM_EXPR. >>>>> >>>>> The following seems to work, and matches what calls.c does when it >>>>> passes a value by reference. Is this what you had in mind? >>>> >>>> Yeah, looks good to me. >>> >>> I don't think that will work reliably (well, maybe now by luck, so better >>> than >>> nothing). You'd at least need to adjust the ESCAPED points-to set of the >>> function, too (yes, DSE does very very conservative use analysis right now). >> >> Ah. >> >>> Why not simply clear MEM_EXPR for the MEM? >> >> The problem is that MEM rtxes aren't shared. AIUI, the store will already >> have been emitted by this point, using a distinct (but equivalent) MEM rtx. > > Again, why doesn't calls.c have to do anything about this when it > passes arguments by reference? It does exactly what I'm changing the > sparc libcall code to do.
calls.c is unsafe, too. Which is probably why making DSE stronger for calls using the usual alias predicates did not work. Richard.