https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118867
--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #16) > Created attachment 60503 [details] > Patch for the canonical of variants > > (In reply to Richard Biener from comment #14) > > We have helpers for folding compares that canonicalize on the fly - we are > > nowhere canonializing such ADDR_EXPRs (to &MEM[&decl + CST]) because of > > object-size and late diagnostics. > > > > VN _should_ have figured this though by means of predication > > > > _30 = listJets.D.31591._M_impl._M_node.D.14392._M_next; > > if (&listJets.D.31591._M_impl._M_node.D.14392 == _30) > > goto <bb 19>; [5.50%] > > else > > goto <bb 9>; [94.50%] -> register > > &listJets.D.31591._M_impl._M_node.D.14392 != _30 > > > > <bb 9> [local count: 118111600]: > > if (&MEM[(struct _List_node_header *)&listJets].D.14392 != _30) > > > > -> find it. Unless there are other edges into BB 9, of course, in which > > case jump-threading is required and likely ranger / relations do not > > record "canonialized" ADDR_EXPRs. > > So one issue with FRE/PRE not figuring out on the predicates is due to the > SSA_NAME NOT being last. > that is insert_predicates_for_cond does nothing is the LHS is NOT a SSA_NAME. > > This attached patch fixes that. and now we get: > > Recording on edge 2->3 a_5 eq_expr &MEM[(struct s2 *)&t].t.node == true > Recording on edge 2->4 a_5 eq_expr &MEM[(struct s2 *)&t].t.node == false > Recording on edge 2->3 a_5 ne_expr &MEM[(struct s2 *)&t].t.node == false > Recording on edge 2->4 a_5 ne_expr &MEM[(struct s2 *)&t].t.node == true > > > But then don't record "canonialized" ADDR_EXPRs nor lookup those up. Ah, so we're recording a EQ_EXPR but for the invariant operand compare we are relying on operand_equal_p. The canonicalization I was thinking of is only performed when the whole operation is a ADDR_EXPR where we go through vn_reference_lookup and try to canonicalize &MEM[p_2 + CST]->x.y.z as p_2 + CST'. operand_equal_p handles some canonicalization of addreses, &MEM[decl] vs &decl, but nothing else. expressions_equal_p could, with PROP_objsz, add an extra "expensive" compare for two ADDR_EXPRs using get_addr_base_and_unit_offset. I also had some old idea of caching offset and a pointer-to-next-variable-component in handled_component_p nodes, but of course we lack space in tree for this. Adding another handled_component_p tree for this or just handling invariants (we have that mandatory recompute_invariant_in_addr_expr thing anyway), storing the info in the ADDR_EXPR as alternate tree (REG_EQUAL like).
