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.
