LOAD_EXTEND_OP crippled

[Daniel Jacobowitz]

On Mon, Jun 14, 2004 at 04:05:15PM -0400, Daniel Jacobowitz wrote:
> The reason I'm looking at this patch is a port I'm working on which defines
> both LOAD_EXTEND_OP (to ZERO_EXTEND) and WORD_REGISTER_OPERATIONS.  I have
> this simple RTL:
> 
> (insn 21 20 22 0 0x403ae0c0 (set (reg:SI 30)
>         (mem/s:SI (reg/f:DI 28) [2 <variable> S4 A32])) 1 {*movsi_insn} (insn_list 19 (nil))
>     (expr_list:REG_DEAD (reg/f:DI 28)
>         (nil)))
> 
> (insn 23 22 24 0 0x403ae0c0 (set (reg:DI 32)
>         (zero_extend:DI (reg:SI 30))) 6 {zero_extendsidi2} (insn_list 21 (nil))
>     (nil))

On Mon, Jun 14, 2004 at 05:42:39PM -0400, Daniel Jacobowitz wrote:
> I have to define an explicit instruction for (set (reg) (zero_extend
> (mem))), which I think is kind of a shame since LOAD_EXTEND_OP implies
> that (set (reg) (mem)) does the zero_extend.  This is needed because
> another part of combine will later turn (set (reg) (subreg:DI (mem:SI))
> back into a zero_extend.  That's assuming that I have the problem
> figured out correctly, since I still can't get the right results
> produced.  But it means my objection to the patch is unfounded.

I eventually got the behavior I wanted, by doing the same thing that
the PowerPC port does: in the movsi expander, emit an explicit
ZERO_EXTEND rtx when possible.  I'm left with my original question,
though: should the combiner be able to do the above?  Curious as to
what people think of that.

It still isn't as good as emiting the ZERO_EXTENDs explicitly, because
then some operations end up zero-extended and others don't; so CSE
extends the lifetimes of both the zero-extended and non-zero-extended
versions.

-- 
Daniel Jacobowitz