On Tue, Jan 26, 2016 at 4:26 PM, Jeff Law <l...@redhat.com> wrote: > On 01/26/2016 02:28 AM, Bin.Cheng wrote: >> >> Yes, loop invariant now increased invariant cost if the invariant >> can't be propagated into address expression. Problem is we check >> propagation by simply replacing use with def in memory reference then >> verifying result insn with verify_changes. Apparently more advanced >> transforms are necessary, just like what combine does. >> I am surprised that rtl_fwprop_addr doesn't handle this either, it's >> an exact address expression propagation example. > > So the question now becomes whether or not the work done by combine.c is > dependent on knowledge that is specific to combine or is it just a series of > transformations that we could make available (preferably moving it to > simplify-rtx). > > If we can factor the transformation out and shove it into simplify-rtx, then > it could be used elsewhere. According to comment at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052#c6, it should be just re-arrangement of operands, if the comment itself holds. In this way, the transformation is backend related, maybe better to keep it in backend, right?
Thanks, bin > > jeff
