On Fri, Sep 18, 2026 at 11:20 AM Andrew Stubbs <[email protected]> wrote: > > 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.
Ok, so for that case pass insn plus rtx * (pointer into insn...) > 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). Indeed ... > Are LLMs allowed for this? I thought those were only approved for > testcases. and maybe tiny edits. > > Andrew
