Hello, On Tue, 17 Mar 2026, Andrew Stubbs wrote:
> > I also think that all those could be fixed as well (e.g. by giving > > up). > > 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.) Chromium and SPECcpu with Ofast? :) Sorry, no particular idea, I guess stuff will show up when it shows up. > > Furthermore I think we somewhen do need a proper representation of the > > concept behind scatter/gather MEMs, where "proper" is not "a RTL > > vec_concat of MEMs". If we went that vec_concat route when vector > > modes were introduced and we had represented vector REGs as a > > vec_concat as well, instead of the current top-level RTL REG, we would > > all be mad by now. > > > > So, IMHO a top-level construct for "N-lane MEM access with N-lane > > addresses" is the right thing to do (and was, for a long time). The > > only question is specifics: should it be a MEM, or a new top-level > > code? Should the only difference between a MEM as-of-now and the vMEM > > be the fact that the address has a vector mode? Or flags on the MEM? > > I would like it to be a MEM for the simple reason that > legitimate_address/legitimize_address allow much more flexibility than > having to match the whole RTL pattern. Just to be clear: when I said "top-level code" I didn't mean anything like a pattern code, but rather a new RTX_OBJ code, i.e. same level as MEM, but possibly with more slots, and possibly without MEM_ATTRs. But that still has the pros and cons that you mention. Yes, I agree that trying with MEM first is the right thing to do. > My prototype legitimate_address+print_operand isn't quite right/finished, but > I think I'll need it permit these: > > ; Straight vector of addresses > (mem (reg:V64DI)) > > ; Vector of addresses, plus scalar offset > (mem (plus:V64DI > (reg:V64DI) > (const_vector:V64DI (const_int)))) > > ; Scalar base, plus vector of offsets > (mem (plus:V64DI > (vec_duplicate:V64DI (reg:DI)) > (zero_extend:V64DI (reg:V64SI)))) > > ; Scalar base, plus vector of offsets, plus scalar offset > (mem (plus:V64DI > (plus:V64DI > (vec_duplicate:V64DI (reg:DI)) > (zero_extend:V64DI (reg:V64SI))) > (const_vector:V64DI (const_int)))) Okay, these read nice and simple enough. In particular they are expressible right now already, so it's a matter of teaching the address recognizers and legitimizers that for that target these forms of addresses/operands are okay. > In each case, the const_vector needs to be the same element repeated. It > could be represented as (vec_duplicate:V64DI (const_int)) also, but that > was less convenient, when I was playing with it. I guess that then would be a target matter, accepting one or the other or both. Not necessarily something that the generic code needs to be concerned with much. (Though, the above constructs seem to have obvious meaning, so teaching the generic code about them may have some value) Ciao, Michael.
