This is the mail archive of the gcc@gcc.gnu.org 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

From: Jeff Law <law at redhat dot com>
To: "Bin.Cheng" <amker dot cheng at gmail dot com>
Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
Date: Tue, 26 Jan 2016 09:26:34 -0700
Subject: Re: Question about how to fix PR69052
Authentication-results: sourceware.org; auth=none
References: <CAHFci280ObgaSxzCBiKKBfKONeYsXOue8i84hH=pDwynhC4PNQ at mail dot gmail dot com> <56A67CD9 dot 70405 at redhat dot com> <CAHFci2_=BHm7x3iv9YrFCb=rhrfpmLfH=CQ-=uy7cOyYRDpiwA at mail dot gmail dot com>

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 isdependent on knowledge that is specific to combine or is it just aseries of transformations that we could make available (preferablymoving it to simplify-rtx).

If we can factor the transformation out and shove it into simplify-rtx,then it could be used elsewhere.


jeff

Follow-Ups:
- Re: Question about how to fix PR69052
  - From: Bin.Cheng

References:
- Question about how to fix PR69052
  - From: Bin.Cheng
- Re: Question about how to fix PR69052
  - From: Jeff Law
- Re: Question about how to fix PR69052
  - From: Bin.Cheng

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