On Mon, Jun 22, 2026 at 6:12 PM Andrew Stubbs <[email protected]> wrote: > > On 18/03/2026 17:12, Andrew Stubbs wrote: > > On 17/03/2026 15:25, Andrew Stubbs wrote: > >> I have run out of places that ICE or cause test failures (for C) when > >> the mode is a vector. Do you have any other suggestions to find them? > >> > >> (I already plan to test C++ and Fortran.) > > > > I found some problems .... > > > > TARGET_POINTER_MODE and TARGET_ADDR_SPACE_POINTER mode only return one > > mode, but now we have multiple valid modes: DImode, V2DImode, V4DImode, > > etc. They also return scalar_int_mode so I can't even invent a new > > address space for the vector pointers. > > > > Same for TARGET_ADDR_SPACE_ADDRESS_MODE. > > > > TARGET_VALID_POINTER_MODE and TARGET_ADDR_SPACE_VALID_POINTER_MODE only > > accept scalar_int_mode, so automatically exclude vector pointers. > > > > These can be patched to use plain machine_mode, perhaps, or keep them > > all scalar and add a new TARGET_ADDR_SPACE_ALLOWS_VECTOR_POINTERS to fix > > the problem at the call sites, which might make more sense? > > I've been working on this proposal some more. I've solved the above > problem by keeping all the hooks returning pointer/address types scalar, > but changing TARGET_ADDR_SPACE_VALID_POINTER_MODE to accept vector > types, so the backend can approve them. When the target independent code > encounters a vector of addresses it checks that the inner mode matches > the appropriate hook values. > > I was hoping to post a patch series this week, but I've hit against > another issue..... > > I have an insn that looks like this: > > (set (reg:V64SI 123) > (vec_merge:V64SI > (mem:V64SI (reg:V64DI 456)) > (reg:V64SI 123) > (reg:DI 789))) > > I.e. a masked load from a vector of addresses in pseudo 456, using a > mask in pseudo 789. > > LRA sometimes tries to transform this by pulling out the MEM: > > (set (reg:V64SI 248) > (mem:V64SI (reg:V64DI 456)) > > (set (reg:V64SI 123) > (vec_merge:V64SI > (reg:V64SI 248) > (reg:V64SI 123) > (reg:DI 789))) > > This looks valid to LRA, but the no-longer-masked memory access causes a > memory fault if the address vector had undefined values in the lanes > that were not intended to be used (which it might well do). > > It does this when I use define_special_memory_constraint (which is what > we had for the previous scheme), but switching to > define_memory_constraint only breaks in a different way: now it tries to > create a new base-address register of type Pmode (arguably, this should > be changed by this project, but it looks to be already broken for > address-spaces with pointer sizes that don't match Pmode). > > I can workaround the "reload" in the backend by using unspecs (exactly > what I was trying to avoid), but does anyone have a better suggestion?
I think that's what all other targets do (x86, to say). Our RTL doesn't really have masked loads/stores as first class citizen. Richard. > > Thanks > > Andrew
