https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113372
--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 15 Jan 2024, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113372 > > --- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #11) > > So the key would be to make the object live again after a CLOBBER when such > > address SSA name is used (but before any other explicit mention appears)? > > > > The current algorithm relies on explitic mentions appearing, one original > > idea was to turn those explicit mentions (or BLOCK starts) into > > start-of-live CLOBBERs, but even that was shown to be not enough. > > > > But yes, if we want to try to mitigate the problems somewhat without > > doing a full solution then possibly even just looking at SSA defs > > when POINTER_TYPE and the def is an ADDR_EXPR might work (in the > > visit_* callbacks of the walk_stmt_load_store_addr_ops), no propagation > > needed at all (basically just undo CSE virtually here for the simple > > cases). > > It couldn't be limited to just POINTER_TYPE, because it mostly is actually > pointer-sized unsigned integer from IVOPTs, but yes, even without full > propagation I think all the testcases I've mentioned could be solved by just > doing the short walks in PHI arguments or other SSA_NAME uses (only PR111422 > needs the latter). > For this PR, we'd need to visit for ivtmp.40_3 uses in PHI args the def-stmt: > ivtmp.40_3 = (unsigned long) &MEM <unsigned long[100]> [(void *)&bitint.6 + > 8B]; > for PR90348 ivtmp.32_28's def-stmt: > ivtmp.32_28 = (unsigned long) ∈ > for PR110115 ivtmp.27_2's def-stmt: > ivtmp.27_2 = (unsigned long) &h; > fpr PR111422 _44's def-stmt: > _44 = &g + _43; > So, if you think it is ok to use just a small hack rather than full > propagation > (which could even handle const/pure calls perhaps if they return pointer or > pointer-sized integer), I can implement that too. Even the full propagation > wouldn't handle everything of course, but could handle more than the small > hack > (which would need to be limited to just say 4 def-stmts and wouldn't try to > look through PHIs). I think we don't expect arbitrary complex obfuscation. We do have RPO order computed so propagation cost would be mostly a bunch of bitmaps (possibly one per SSA name), but with PHIs we'd need to iterate. I wonder if this could be done along the propagation add_scope_conflicts does itself - can we do this within add_scope_conflicts_1 when for_conflict == false? I'd think so (though whether a change occured is more difficult to track?). What would you then consider a mention that's not explicit? Any that we couldn't further propagate to its uses? Thus also mem = _1; with _1 having the address of some local?
