This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: peephole or expand optimization for fixing poor code generated in conversion from QImode to PSImode pointer?


On Mon, Sep 23, 2019 at 1:56 PM Jozef Lawrynowicz <jozefl.gcc@gmail.com> wrote:
>
> For msp430-elf in the large memory model there are PSImode (20-bit) pointers.
> POINTERS_EXTEND_UNSIGNED == 1 and "char" is unsigned by default.
>
> We get poor code generated for the following code snippet:
>
> const int table[2] = {1, 2};
>
> int
> foo (char i)
> {
>   return table[i];
> }
>
> The RTL generated by expand uses two insns to convert "i" to a register's
> natural mode; there is a sign extension which would be unnecessary if the first
> instruction had a PSImode register as the lvalue:
>
> (insn 2 4 3 2 (set (reg/v:HI 25 [ i ])
>         (zero_extend:HI (reg:QI 12 R12 [ i ])))
>      (nil))
> .....
> (insn 7 6 8 2 (set (reg:PSI 28)
>         (subreg:PSI (sign_extend:SI (reg/v:HI 25 [ i ])) 0))
>      (nil))
>
> All we really need is:
>
> (insn (set (reg:PSI 28 [ i ])
>         (zero_extend:PSI (reg:QI 12 R12 [ i ])))
>      (nil))
>
> The zero extend is implicit with byte sized register operations, so this would
> result in assembly such as:
>   MOV.B R12, R12
>
> My question is whether this is the type of thing that should be handled with a
> peephole optimization or if it is worth trying to fix the initial RTL generated
> by expand (or in a later RTL pass e.g. combine)?

The C frontend promotes 'i' already and likely that promotion "sticks" via
your choice of SIZETYPE.

But yes, preferably RTL expansion would behave better here.

Richard.

>
> Thanks,
> Jozef


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]