This is the mail archive of the gcc-patches@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: [PATCH] PR 62173, re-shuffle insns for RTL loop invariant hoisting

On 12/19/2014 06:26 AM, Richard Biener wrote:

On Fri, Dec 19, 2014 at 11:28 AM, Jiong Wang
<wong.kwongyuan.tools@gmail.com> wrote:

2014-12-19 3:51 GMT+00:00 Bin.Cheng <amker.cheng@gmail.com>:

On Fri, Dec 19, 2014 at 6:09 AM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:

On Thu, Dec 18, 2014 at 05:00:01PM +0000, Jiong Wang wrote:

On 17/12/14 15:54, Richard Biener wrote:

ick.  I realize we don't have SSA form on RTL but doesn't DF provide
at least some help in looking up definition statements for pseudos?
In fact we want to restrict the transform to single-use pseudos, thus
hopefully it can at least tell us that... (maybe not and this is what
LOG_LINKS are for in combine...?)  At least loop-invariant alreadly
computes df_chain with DF_UD_CHAIN which seems exactly what
is needed (apart from maybe getting at single-use info).

thanks very much for these inspiring questions.

yes, we want to restrict the transformation on single-use pseudo only,
and it's better the transformation could re-use existed info and helper
function to avoid increase compile time. but I haven't found anything I
can reuse at the stage the transformation happen.

the info similar as LOG_LINKS is what I want, but maybe simpler. I'd study
the code about build LOG_LINKS, and try to see if we can do some factor out.

LOG_LINKs in combine are just historical.  combine should be converted
to use DF fully.

As noted loop-invariant already computes DF use-def chains.  The question
is whether it does compute single-use info when doing that (should be trivially
possible).  Kenny?
In the US, (where i live), there is something called the "statute of limitations" which says that after 7 years you cannot be found accountable for anything except the most heinous of crimes. It has been more than 7 years since i did this. 

however, since i am a nice person ....
loop-invariant solves the DF_UD_CHAIN which builds a data structure that connects each use with all of the defs that reach it. I believe that this is the opposite of what you want here.
if you really need this, you need to also turn on the DF_DU_CHAIN which builds the opposite structure. Both structures can be space hogs, but they are both turned on in other places in the compiler so it is unlikely to be an issue. 





LOG_LINKs have nothing to do with single use; they point from the _first_
use to its corresponding def.

You might want to look at what fwprop does instead.

Pass rtl fwprop uses df information in single-definition way, it
doesn't really take into consideration if register is a single use.
This often corrupts other optimizations like post-increment and
load/store pair.  For example:

   add r2, r1, r0
   ldr rx, [r2]
   add r2, r2, #4
is transformed into below form:
   add r2, r1, r0
   ldr rx, [r1, r0]
   add r2, r2, #4

As a result, post-increment opportunity is corrupted, also definition
of r2 can't be deleted because it's not single use.

Thanks,
bin

thanks for all these suggestion.

Have look at the LOG_LINK build function, a simple reverse scan, while
needs to allocate big map array for all pseudo regs. Haven't looked at
similar code in fwprop,

actually, when found the first matched insn pattern, I just want to
scan several insns next, then abort quickly if nothing meet
requirement. there is no need to build full single-use information.

still can anyone confirm that it is safe to re-use REG_DEAD info there
without calling df_note_add_problem and df_analysis first? or I am
using those info passed down from the previous pass which calculated
these info and maybe broken?

It's not safe to use REG_DEAD info without re-computing it.
not sure that reg_dead is the right answer even if you did re-compute it. I believe you can have two parallel uses (on both sides of an if-then-else) for a single def (above the if then else) and have two REG_DEAD notes. 


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