On 09/07/2026 16:16, Jeffrey Law wrote:
On 7/8/2026 8:53 AM, Andrew Stubbs 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.
I guess I'm still struggling with what context you're looking at outside
the MEM. It looks like you walk the insn recording either the first
vector memory operand or the last memory operand, but that's the only
context you pull out of INSN AFAICT. So I could perhaps guess that the
existence of a vector MEM operand cases you to potentially want to
adjust the class for some other operand?
Not objecting, just trying to understand motivation.
The ISA has only one way to load vectors*: a vector of absolute
addresses goes in, and a vector of data comes out. The address vector
needs to be in the VGPR_REGS register class.
But, the compiler doesn't generate address vectors when it does stack
spills and reloads, so we also support the more normal base address
style of addressing, and then convert it later using a split. In that
case the base address needs to be in class SGPR_REGS (or else the
vec_duplicate instruction won't work).
But, confusingly, when we load scalar values, in some address spaces,
they have to be loaded into lane 0 of a vector register, in which case
the correct class is VGPR_REGS, again.
You can't tell which variety of address is in use just by looking at the
mode and address space by themselves (which is all we have in the
regular hook): it could be DImode or V64DImode. By looking at the whole
MEM we can see the whole picture. Actually all we need to see is the
mode of the address expression.
When IRA uses base_reg_class with a null insn we can assume that it's
inquiring about a reload and make a choice based solely on the data
mode. Anywhere else in the compiler the address mode is needed to
determine the proper class.
As I said, INSN_BASE_REG_CLASS is the solution we have; some variant of
MODE_CODE_BASE_REG_CLASS that also has the address mode would have been
sufficient (the codes are actually not useful, but that's the one that
has the address space).
Previously, we did not have this problem because the address vector case
did not use a MEM (it required an UNSPEC), and therefore did not trigger
any base_reg_class hook.
Andrew
* There are other graphics-oriented instructions, but those require a
four-register descriptor with many bit-fields and the compiler doesn't
use them.
