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 01/26/2016 09:36 AM, Bin.Cheng wrote:
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

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?
I'd like to see the key RTL heading into ix86_decompose_address -- mostly to make sure it's not being passed non-canonical RTL or somesuch.


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