[PATCH: PR target/44999] Replace "and r0, r0, #255" with uxtb in thumb2

[Carrot Wei]

1. Why is HImode different to QImode?

Actually it is not HImode VS QImode, it is 65535 VS 255. The actual
processing of and with constant is handled by function
arm_gen_constant. In this function it finds that 255 can be directly
encoded in an and instruction, so it generates a simple and
instruction. On the other hand, 65535 can't be  directly encoded in an
and instruction, it must find some other ways to handle it, then it
find this and can be accomplished with two shifts. In the later
combine pass, the two shifts are combined into a single uxth.

2. Why do we need it for Thumb mode, and not for ARM mode?

In thumb mode, instruction and with constant is 32 bit, uxtb is 16
bit, with this enhancement we can save 2 bytes.
In ARM mode, all instructions are 32 bit, convert and to uxtb doesn't
help us, so we don't care which instruction is used.
So we need it for Thumb mode only.

thanks
Carrot

On Mon, Nov 8, 2010 at 7:55 PM, Paul Brook <paul@codesourcery.com> wrote:
>> > Even ignoring that, I don't think this is the right fix. Why do we need
>> > this for Thumb mode, and not ARM mode? Why extendqi and not extendhi?
>>
>> In Thumb mode, and with a constant is 32 bit, and uxtb is 16 bit.
>> In ARM mode, both are 32 bit, so it is not beneficial.
>> The test case shows that and with 0xFFFF is already converted to uxth,
>> so it is not handled here.
>
> I'm still not convinced. Why is HImode different to QImode? Why has this
> suddenly changed? Why does gcc generate uxtb in ARM mode but not Thumb mode?
> i.e. I've little confidence that this is actually fixing the problem rather than
> papering over a bug elsewhere, especially given we have a perfectly good
> zero_extendqisi2 pattern+expander.
>
> Paul
>