This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question about how to fix PR69052

On Tue, Jan 26, 2016 at 4:26 PM, Jeff Law <> 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, 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?

> jeff

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]