Re: gcc 4.6.1 expand is playing tricks on me

["Paulo J. Matos" <pocmatos at gmail dot com>]

On 08/07/11 15:35, Michael Matz wrote:
> Without TERing these two instructions expand won't see both memory
> references at the same time, and hence generate separate load and store
> instruction, instead of a mem-mem move if that's supported on your target
> (I assume so, otherwise you wouldn't have noticed).
>
> The question is, why doesn't combine merge the two separate load and store
> insns again into one?

I got it! Thanks Michael.
The answer to your last question is that we don't support memory to 
memory moves.

The situation is a bit more complex. When we see
(set (mem:HI (reg:HI 0)) (mem:HI (reg:HI 1)))

we have a rule that expands this to 4 insn
(set (reg:QI AL) (mem:QI (plus (reg:HI 1) (const_int 1))))
(set (reg:QI AH) (mem:QI (reg:HI 1)))
(set (mem:QI (plus (reg:HI 0) (const_int 1))) (reg:QI AL))
(set (mem:QI (reg:HI 0)) (reg:QI AH))

because we know that using AL and AH as intermediate registers is the 
only way to go in this case. This is then modified slightly by combine, 
etc to generate optimal code.

When GCC 4.6.1 generates two insn dealing with HI so we never have the 
opportunity to introduce these set of 4 insn. The resulting code is less 
than perfect.

However, you hinted to using combine. I am wondering if I can combine 
and into a memory-memory move in HImode and straight away split into the 
4 insn above. In the end 4.6.1 would end up doing the same at combine 
time as 4.5.3 in expand time. I have to look at it once again.

As a last resort I might try your patch, however I try to touch the core 
as little as possible. We already have enough patches to deal with 16 
bit words, chars, wide chars, fn ptrs size != data ptrs size, etc. :)

Thank you very much for your explanation and tips.

Cheers,

Paulo Matos