On Wed, Jul 8, 2026 at 4:54 PM Andrew Stubbs <[email protected]> wrote:
>
> On 07/07/2026 00:28, Jeffrey Law wrote:
> >
> >
> > On 7/2/2026 2:28 AM, Andrew Stubbs wrote:
> >> The INSN_BASE_REG_CLASS macro is useful for getting full context on
> >> real insns,
> >> but isn't very helpful for targets that have multiple address spaces and
> >> therefore no single default when the insn context is not available. This
> >> patch allows multiple macros to exist simultaneously: INSN_BASE_REG_CLASS
> >> is used as first preference, and another macro is selected when INSN is
> >> null.
> >>
> >> The only existing user of INSN_BASE_REG_CLASS (x86) returns
> >> BASE_REG_CLASS
> >> when INSN is null, so this change should be safe.
> >>
> >> Additionally, there were a few cases where base_reg_class was called
> >> without an
> >> insn, even though it was known. These bypassed the preferred macro, so
> >> the
> >> patch fixes them up.
> >>
> >> gcc/ChangeLog:
> >>
> >> * addresses.h (base_reg_class): Don't call INSN_BASE_REG_CLASS with
> >> null insn.
> >> * doc/tm.texi: Document new INSN_BASE_REG_CLASS behaviour.
> >> * doc/tm.texi.in: Likewise.
> >> * regcprop.cc (replace_oldest_value_mem): Pass insn to
> >> base_reg_class.
> >> * regrename.cc (base_reg_class_for_rename): Likewise.
> > So I don't see anything concerning, but I don't see any discussion of
> > how you want to use this new capability. Nor do I see anything WRT
> > testing.
>
> I've now posted the patch series that inspired this. Please see
> https://gcc.gnu.org/pipermail/gcc-patches/2026-July/723225.html
>
> The new address vectors feature requires that I can tell in which
> context the address occurs in order to know what class to propose. A
> new hook that passes the whole MEM would be more precise (avoid
> ambiguity with insns that have multiple MEMs), but the
> INSN_BASE_REG_CLASS is the best solution from those currently available.
>
> The problem with what to do with "null" came up in the development of
> that feature, and it was tested in that context.
The whole setup looks a bit like a (historical) mess. I suppose the
earlier tested macros are the newest and given there's a single
target defining INSN_BASE_REG_CLASS I'd rather see either
a) make sure insn is never NULL!
b) change INSN_BASE_REG_CLASS to, in addition to 'insn',
also receive all the other arguments, thus make it
MODE_CODE_BASE_REG_CLASS plus insn argument
bonus points for eliminating all the legacy and turning this
into a hook! LLMs to the rescue!
Richard.
>
> Andrew
