[PATCH] i386: Add peephole for lea and zero extend [PR 101716]

Uros Bizjak ubizjak@gmail.com
Mon Aug 16 09:26:38 GMT 2021


On Mon, Aug 16, 2021 at 11:18 AM Hongyu Wang <wwwhhhyyy333@gmail.com> wrote:
>
> > So, the question is if the combine pass really needs to zero-extend
> > with 0xfffffffe, the left shift << 1 guarantees zero in the LSB, so
> > 0xffffffff should be better and in line with canonical zero-extension
> > RTX.
>
> The shift mask is generated in simplify_shift_const_1:
>
> mask_rtx = gen_int_mode (nonzero_bits (varop, int_varop_mode),
>                          int_result_mode);
> rtx count_rtx = gen_int_shift_amount (int_result_mode, count);
> mask_rtx
>   = simplify_const_binary_operation (code, int_result_mode,
>                                      mask_rtx, count_rtx);
>
> Can we adjust the count for ashift if nonzero_bits overlaps it?
>
> > Also, ix86_decompose_address accepts ASHIFT RTX when ASHIFT is
> > embedded in the PLUS chain, but naked ASHIFT is rejected (c.f. the
> > call in ix86_legitimate_address_p) for some (historic?) reason. It
> > looks to me that this restriction is not necessary, since
> > ix86_legitimize_address can canonicalize ASHIFT RTXes without
> > problems. The attached patch that survives bootstrap and regtest can
> > help in your case.
>
> We have a split to transform ashift to mult, I'm afraid it could not
> help this issue.

If you want existing *lea<mode> to accept ASHIFT RTX, it uses
address_no_seg_operand predicate which uses address_operand predicate,
which calls ix86_legitimate_address_p, which ATM rejects ASHIFT RTXes.

Uros.


More information about the Gcc-patches mailing list