https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66156
--- Comment #3 from Ronald Wahl <ronald.wahl at raritan dot com> ---
(In reply to Nick Clifton from comment #1)
> Hi Ronald,
>
> What's going on is that this is a reload bug. Reload wants to extend r42
> into r43 (or rather r12 into r10) and it is assuming that the
> zero_extendhisi pattern will do this. Unfortunately it does not, it only
> extends in place, and so an extra move is required to make the conversion
> complete. Reload generates this extra move, but of course it is too late,
> r13 has already been clobbered.
>
> Not being a reload guru, I have decided to take the easy way out and
> extend the zero_extendhisi2 pattern so that it can cope with moving the
> value whilst extending it. This works, although it does still leave a
> potential bug in reload for other targets. But for now it is the simplest
> solution. So I am going to apply this patch to the msp430 sources. Please
> let me know if you have any problems with it.
Looks good. Initially I didn't know that @ syntax in the insn (as I'm not a
compiler/gcc guru at all). Now it's clear to me so I have actually learned
something. :-)
Anyway, at the moment the compiler generates
MOV.W @R12, R12
MOV.W R12,R10 { MOV.W #0,R11
without using R12 afterwards so if it would generate
MOV.W @R12, R10
MOV.W MOV.W #0,R11
it would be even better. But this is just nitpicking. Maybe the LRA backend you
are working on will do a better job later. ;-)
- ron
