On Tue, Aug 24, 2021 at 5:22 PM Hongyu Wang <wwwhhhyyy...@gmail.com> wrote:
>
> Hi Uros,
>
> Sorry for the late update. I have tried adjusting the combine pass but
> found it is not easy to modify shift const, so I came up with an
> alternative solution with your patch. It matches the non-canonical
> zero-extend in ix86_decompose_address and adjust ix86_rtx_cost to
> combine below pattern
>
> (set (reg:DI 85)
> (and:DI (ashift:DI (reg:DI 87)
> (const_int 1 [0x1]))
> (const_int 4294967294 [0xfffffffe])))
>
> Survived bootstrap and regtest on x86-64-linux. Ok for master?
gcc/ChangeLog:
PR target/101716
* config/i386/i386.c (ix86_live_on_entry): Adjust comment.
(ix86_decompose_address): Remove retval check for ASHIFT,
allow non-canonical zero extend if AND mask covers ASHIFT
count.
(ix86_legitimate_address_p): Adjust condition for decompose.
(ix86_rtx_costs): Adjust cost for lea with non-canonical
zero-extend.
OK.
Thanks,
Uros.
> Uros Bizjak <ubiz...@gmail.com> 于2021年8月16日周一 下午5:26写道：
>
> >
> > On Mon, Aug 16, 2021 at 11:18 AM Hongyu Wang <wwwhhhyyy...@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.
