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.
Andrew
