Re: Unnesting of nested subreg expressions

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

Björn Haase wrote:
> misses therefore a lot of optimizations. I am presently trying to remove the 
> define_insn for the HImode and SImode operations by implementing the lowering 
> to QImode at expand or at least after reload (for those operations that leave 
> the condition code in a useable state like addsi3 ).

optabs.c can do some of this work for you.  E.g., if there is an andqi 
pattern but not andhi pattern, and word_mode == QImode, then 
expand_binop will automatically synthesize an andhi operation from the 
andqi pattern.  So the easy solution here is to simply not define andhi. 
 If the RTL you get isn't optimal, then you can add your own pattern 
that uses machine dependent instructions.  This shouldn't be necessary 
for and, but may be necessary for add.

Take a look at how this code in expand_binop works.  It uses 
operand_subword/operand_subword_force, which is the standard way to 
extract sub-words from a multiple word value.

>   [(set (subreg:QI (match_dup 0) 0)
>         (and:QI (subreg:QI (match_dup 1) 0)
>                 (subreg:QI (match_dup 2) 0)))
>    (set (subreg:QI (match_dup 0) 1)
>         (and:QI (subreg:QI (match_dup 1) 1)
>                 (subreg:QI (match_dup 2) 1)))]

The explicit subregs in the RTL here isn't a good idea.  It is probably 
better to make these be QImode match_operands, and then generate RTL for 
the operands includes the SUBREGs.

The REG_P check should prevent any subreg from getting through to here, 
so it isn't clear how your nested subreg happened.  Anyways, I think the 
answer here is "operand_subword" instead of gen_lowpart/gen_highpart.  I 
 don't remember if operand_subword works for constants though, it might 
only be right for the register/subreg case.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com