On 4/11/19 3:26 AM, Richard Biener wrote: > On Thu, 11 Apr 2019, Jakub Jelinek wrote: > >> On Thu, Apr 11, 2019 at 09:54:24AM +0200, Richard Biener wrote: >>>> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? >>>> >>>> During those 2 bootstraps/regtests, data.load_found has been set just >>>> on the new testcase on ia32. >>> >>> Hmm, I wonder whether we really need to DCE calls after reload? >>> That said, I'm not familiar enough with the code to check if the >>> patch makes sense (can there ever be uses of the argument slots >>> _after_ the call?). >> >> And here is the patch on top of the refactoring patch. >> As for the argument slots after the call, hope Jeff and Vlad won't mind if I >> copy'n'paste what they said on IRC yesterday: >> law: vmakarov: in PR89965, is it valid RTL to store something in stack >> argument slot and read it again before the call that uses that stack slot? >> law: vmakarov: if yes, I have a rough idea what to do, but if stack argument >> slots may be only stored and can be read only by a callee and not by >> something else in the caller, then it is a RA issue >> <vmakarov> jakub: i think it is not defined (or described). But the old >> reload used equiv memory for long time to store value in memory. LRA just >> uses the same approach. >> <law> i think you're allowed to read it up to the call point, who "owns" the >> contents of the slot after the call point is subject to debate :-) >> <law> not sure if we defined things once a REG_EQUIV is on the MEM, but that >> would tend to imply the memory is unchanging across the call >> <law> (though one could ask how in the world the caller would know the >> callee didn't clobber the slot....) > > Ok, so that says "well, nothing prevents it from being used" for example > for a const/pure call (depending on what alias analysis does here...). Agreed.
> Who owns the argument slots should be defined by the ABI I guess. Agreed, but I'm not sure it's consistently defined by ABIs. > > So iff alias-analysis doesn't leave us with the chance to pick up > the stack slot contents after the call in any case we're of course fine. > And if we do have the chance but should not then the call instruction > needs some explicit clobbering of the argument area (or the RTL IL > needs to be documented that such clobbering is implicit and the > alias machinery then needs to honor that). I suspect the only way we currently get into this state is around const/pure calls. One could imagine a day where we do strong alias analysis across calls and could make more precise annotations about how the callee uses/modifies specific memory locations. Jeff
