On 18/09/2026 10:08, Richard Biener wrote:
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!
I've actually just run into a new problem with this macro: if INSN
contains multiple MEMs then there's no way to tell which one the caller
is interested in. I am working on a new patch that uses the mode and
address space to at least narrow it down (base_reg_class itself does not
know), and consequently does not need the fallback behaviour; so
basically your point (b) already.
I don't think it's possible to prevent INSN being null because some of
the callers (e.g. init_caller_save) are asking for general answers
(unless we have them synthesize an insn for the purpose of the call).
Are LLMs allowed for this? I thought those were only approved for
testcases. and maybe tiny edits.
Andrew
