Re: [PATCH] loading float member of parameter stored via int registers

[Jiufu Guo <guojiufu@linux.ibm.com>]

Hi,

Segher Boessenkool <segher@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 <segher@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