On Wed, 14 Jun 2023, Richard Sandiford wrote: > Richard Biener <rguent...@suse.de> writes: > > On Wed, 14 Jun 2023, Richard Sandiford wrote: > > > >> Richard Biener <rguent...@suse.de> writes: > >> > AFAIU this special instruction is only supposed to prevent > >> > code motion (of stack memory accesses?) across this instruction? > >> > I'd say a > >> > > >> > (may_clobber (mem:BLK (reg:DI 1 1))) > >> > > >> > might be more to the point? I've used "may_clobber" which doesn't > >> > exist since I'm not sure whether a clobber is considered a kill. > >> > The docs say "Represents the storing or possible storing of an > >> > unpredictable..." - what is it? Storing or possible storing? > >> > >> I'd also understood it to be either. As in, it is a may-clobber > >> that can be used for must-clobber. Alternatively: the value stored > >> is unpredictable, and can therefore be the same as the current value. > >> > >> I think the main difference between: > >> > >> (clobber (mem:BLK ?)) > >> > >> and > >> > >> (set (mem:BLK ?) (unspec:BLK ?)) > >> > >> is that the latter must happen for correctness (unless something > >> that understands the unspec proves otherwise) whereas a clobber > >> can validly be dropped. So for something like stack_tie, a set > >> seems more correct than a clobber. > > > > How can a clobber be validly dropped? For the case of stack > > memory if there's no stack use after it it could be elided > > and I suppose the clobber itself can be moved. But then > > the function return is a stack use as well. > > > > Btw, with the same reason the (set (mem:...)) could be removed, no? > > Or is the (unspec:) SET_SRC having implicit side-effects that > > prevents the removal (so rs6000 could have its stack_tie removed)? > > > > That said, I fail to see how a clobber is special here. > > Clobbers are for side-effects. They don't start a def-use chain. > E.g. any use after a full clobber is an uninitialised read rather > than a read of the clobber ?result?.
I see. So (parallel (unspec stack_tie) (clobber (mem:BLK ...))) then? I suppose it needs to be an unspec_volatile? It feels like the stack_ties are a delicate hack preventing enough but not too much optimization ... > In contrast, a set of memory with an unspec source is in dataflow terms > the same as a set of memory with a specified source. (some unspecs > actually have well-defined values, it's just that only the target code > knows what those well-defined value are.) > > So a set of memory could only be removed if DSE proves that there are no > reads of the set bytes before the next set(s) to the same bytes of memory. > And memory is always live. > > Thanks, > Richard > > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)
