On March 4, 2016 5:35:13 PM GMT+01:00, "Bin.Cheng" <amker.ch...@gmail.com> wrote: >On Fri, Mar 4, 2016 at 11:57 AM, Richard Biener ><richard.guent...@gmail.com> wrote: >> On Fri, Mar 4, 2016 at 12:07 PM, Bin Cheng <bin.ch...@arm.com> wrote: >>> Hi, >>> A address canonicalization interface was introduced by my original >patch to PR69052. The interface sorts sub-parts in an address >expression based on precedences defined by function >commutative_operand_precedence. It also assumes that all CONST_INT >sub-parts are at the end of vector after sorting. But this is not >always true because commutative_operand_precedence sets the same >precedence to both CONST_INT and CONST_WIDE_INT. The patch could be >broken in cases which have CONST_WIDE_INT sorted after CONST_INT. Even >though I don't think we can really run into such complicated case, I >worked out a patch forcing CONST_INT to lower precedence than >CONST_WIDE_INT, so that for sure it will be sorted after all other >kinds sub-parts. >>> >>> This is an obvious change. Bootstrap&test on x86_64, bootstrap&test >on AArch64. Is it OK for this stage? >> >> I believe the obvious change would be to change >> commutative_operand_precedence to pre-CONST_WIDE_INT behavior, namely >> giving CONST_WIDE_INT the same precedence as CONST_DOUBLE. >Yes, but I am not sure what else this change will affect, so I made >the smallest change in the original code.
I don't like going with this kind of weirdo changes out of caution. If you think it's too dangerous the push it back to gcc 7 and consider backporting for 6.2 I am testing this now. It >would be great if anyone describes it a bit. Thanks, Richard. > >Thanks, >bin >> >> Richard. >> >> >> >>> Thanks, >>> bin >>> >>> 2016-03-04 Bin Cheng <bin.ch...@arm.com> >>> >>> PR rtl-optimization/69052 >>> * loop-invariant.c (compare_address_parts): Force CONST_INT >to lower >>> precedence than CONST_WIDE_INT.
