Re: Unnesting of nested subreg expressions

[James E Wilson <wilson at specifixinc dot com>]

Björn Haase wrote:
> The mid-end seems not to be able to simplify nested subreg expressions. I.e. 
> it seems that there is no known transformation 
>    (subreg:QI (subreg:HI (reg:SI xx) 0) 0) 

Nested subregs aren't valid.  You should refrain from creating them.

> (define_expand "xorhi3"
>  [(set (subreg:QI (match_operand:HI 0 "register_operand" "=r") 0)
>        (xor:QI (subreg:QI (match_operand:HI 1 "register_operand" "%0") 0)
>                (subreg:QI (match_operand:HI 2 "register_operand" "r")  0)))
>   (set (subreg:QI (match_dup 0) 1)
>        (xor:QI (subreg:QI (match_dup 1) 1)
>                (subreg:QI (match_dup 2) 1)))]


If you have 16-bit registers, then I don't think there is any way to 
make this work as written.  Intra-register high-part subregs aren't 
generally valid either.  A high-part subreg is generally only valid when 
it is an entire-register of a multi-register value.

You will have to use some other kind of rtl here, such as shift and 
masks, or zero_extract.

> It seems that the cleanest solution would be to teach gcc how to unnest 
> subregs. Therefore my question: Is this possible and where would be the place 
> for doing this?

Or you can fix your expander to stop creating nested subregs.  That is 
proabably much simpler than trying to teach the rest of the compiler to 
accept them.

You can't rely on the fact that any expanded rtl will get simplified, so 
if we allow nested subregs, then everyplace that handles them needs to 
accept them, and that means an awful lot of code will have to change.

> BTW. I have stepped over a similar issue when using the gen_highpart and 
> gen_lowpart functions for splitters after reload.

I can't comment without details.

> are working on a label reference immediate operand. It seems that in their 
> present form gen_lowpart and gen_highpart should be used only in DI-SI-mode 
> splitters since then there is no danger that the DI mode expression itself is 
> a subreg of an even larger mode.

Except that the DImode expression could be a paradoxical subreg of a 
smaller mode, in which case you might have similar problems.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com