Hi, Segher Boessenkool <seg...@kernel.crashing.org> writes:
> On Fri, Dec 23, 2022 at 08:13:48PM +0100, Richard Biener wrote: >> > Am 23.12.2022 um 17:55 schrieb Segher Boessenkool >> > <seg...@kernel.crashing.org>: >> > There are at least six very different kinds of subreg: >> > >> > 0) Lvalue subregs. Most archs have no use for it, and it can be >> > expressed much more clearly and cleanly always. >> > 1) Subregs of mem. Do not use, deprecated. When old reload goes away >> > this will go away. >> > 2) Subregs of hard registers. Do not use, there are much better ways to >> > write subregs of a non-zero byte offset, and for zero offset this is >> > non-canonical RTL. >> > 3) Bitcast subregs. In principle they go from one mode to another mode >> > of the same size (but read on). >> > 4) Paradoxical subregs. A concept completely separate from the rest, >> > different rules for everything, it has to be special cased almost >> > everywhere, it would be better if it was a separate rtx_code imo. >> > 5) Finally, normal subregs, taking a contiguous span of bits from some >> > value. >> > >> > Now, it is invalid to have a subreg of a subreg, so a 3) of a 5) is >> > written as just one subreg, as you say. And a 4) of a 5) is just >> > invalid afaics (and let's not talk about 0)..2) anymore :-) ) >> > >> >> Note whether targets actually support subreg operations needs to be >> >> queried and I’m not sure how subreg with offset validation should work >> >> there. >> > >> > But 3) is always valid, no? On pseudos I also has similar question: do we need to query/recog if "SF(SI#0)" is valid on the target, or it would always work (even through reload)? I also hit this during debugging on ppc64le: "SF(SI#0)" is valid, and "SF(DI#4)" is not valid. >> >> Yes, but it will eventually result in a spill/reload which is >> undesirable when we created this from CSE from a load. So I think >> for CSE we do want to know whether a spill will definitely not >> occur. > > Does it cause reloads though? On any sane backend? If no movsf pattern > allows integer registers, can things work at all? > > Anyway, the normal way to test if some RTL is valid is to just generate > it (using validate_change) and then do apply_change_group, which then > cancels the changes if they do not work. CSE already does some of > this. validate_change seems ok. Thanks! > > (I am doubtful doing any of this in CSE is a good idea fwiw). Understand your concern! Especially when we need to emit additional inns in CSE. While CSE does some similar work. It transforms "[sf:DI]=%x:DI; %y:DI=[sf:DI]" to "%y:DI=%x:DI". and "see if a MEM has already been loaded with a widening operation; if it has, we can use a subreg of that." (only for int modes). So, it may be acceptable to do this in CSE (maybe still seems hacking). Thanks for so great comments! BR, Jeff (Jiufu) > > > Segher
