On Mon, Sep 15, 2025 at 9:29 PM Eric Botcazou <botca...@adacore.com> wrote: > > > Yes. So I read the comment in a way to say that TREE_THIS_NOTRAP does not > > mean the reference is writable. In some context we check > > > > || tree_could_trap_p (lhs) > > > > /* tree_could_trap_p is a predicate for rvalues, so check > > for readonly memory explicitly. */ > > > > || ((base = get_base_address (lhs)) > > > > && ((DECL_P (base) > > && TREE_READONLY (base)) > > > > || TREE_CODE (base) == STRING_CST))) > > > > return false; > > > > but I guess even for !DECL_P base but tcc_reference base TREE_READONLY > > could be set? I've never seen that though. Not having TREE_READONLY set > > on some handled-component doesn't mean a ref is writable, right? So it's > > kind of a useless flag when put on reference trees? > > Do you mean TREE_READONLY or TREE_THIS_NOTRAP is a useless flag? In my view > they mean different and orthogonal things. We do propagate TREE_READONLY in > the inliner and the tree rewriting routines too.
I mean TREE_READONLY on ..._REF nodes. We can't rely on the absence of TREE_READONLY on ..._REF meaning the object is writable, so the flag does not add any information (but maybe some costing hint that the object is definitely _not_ writable(?)). The above snippet from tree-ssa-phiopt.cc (cselim) also hints at that seeing a write LHS where tree_could_trap_p () is false does not mean the object is writable. This relies on tree_could_trap_p () only ever returning false for DECL-based accesses or accesses with TREE_THIS_NOTRAP - but it fails to consider the latter for the readonly check. I also wonder whether for TREE_THIS_NOTRAP non-DECL-based accesses a TREE_READONLY flag is required when the object accessed _might_ be readonly. Consider if (readonly) ptr = &readonly_decl; else ptr = &writable_decl; if (!readonly) *ptr = 1; if *ptr has TREE_THIS_NOTRAP set, what would the presence or absence of TREE_READONLY tell us? If it doesn't have TREE_THIS_NOTRAP set, same question. Richard. > > -- > Eric Botcazou > >
