This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] PR 62173, re-shuffle insns for RTL loop invariant hoisting
- From: Kenneth Zadeck <zadeck at naturalbridge dot com>
- To: Jiong Wang <wong dot kwongyuan dot tools at gmail dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, "Bin.Cheng" <amker dot cheng at gmail dot com>, Segher Boessenkool <segher at kernel dot crashing dot org>, Jiong Wang <jiong dot wang at arm dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 11 Feb 2015 09:21:59 -0500
- Subject: Re: [PATCH] PR 62173, re-shuffle insns for RTL loop invariant hoisting
- Authentication-results: sourceware.org; auth=none
- References: <54803EBE dot 2060607 at arm dot com> <CAFiYyc1jauY_hejCfgU88DXtaSCCSZDUMiKMb678KqQ_QrMzrQ at mail dot gmail dot com> <CAFiYyc0gEQt_Ci1TyCfYys=JnZMr8FmYW7dFtq+mBmqKjeuttw at mail dot gmail dot com> <5480B6D6 dot 2020201 at arm dot com> <548EFE0D dot 1070808 at arm dot com> <548EFE55 dot 6090901 at arm dot com> <CAFiYyc3oYRsYkQwivE+T4A4mysDBe0gjZqjroQ8B2p1J6sakQg at mail dot gmail dot com> <54930811 dot 1020003 at arm dot com> <20141218220908 dot GA20720 at gate dot crashing dot org> <CAHFci28ajc8KqKEvyYYvQHbhYkZ-ExV8ixJ+SNuqV8bg3n7JJQ at mail dot gmail dot com> <CAAfDdZ0EZ6EVN_wYFFuh81ptL2c_Em-Ub-2s4GO7Vp0QKjd-=Q at mail dot gmail dot com> <CAFiYyc32CJJTjakxMLjkCQAJLrv1u0PSjifTs=A4V4q4nOFTKg at mail dot gmail dot com> <5494426A dot 9010209 at naturalbridge dot com> <CAAfDdZ2xrfRYoD8eO1L+8StWh53OhFNBy4ZMRt-K4xSj6r64eA at mail dot gmail dot com>
On 02/11/2015 06:20 AM, Jiong Wang wrote:
You now are beginning to understand why Mark Wegman and I invented SSA
form almost 30 years ago!!!! There is no good way to keep the
information up to data as you are changing the program. To a large
extent you are on your own. If what you are suggesting works, then
this is likely much faster than rebuilding the chains.
2014-12-19 15:21 GMT+00:00 Kenneth Zadeck <firstname.lastname@example.org>:
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.
Exactly, Thanks, Kenneth.
This approach works from my experiment and look much better than
previous REG_NOTE approach.
while it do have one problem. We need the UD/DU chain built before we
do insn re-shuffling.
While after re-shuffling, UD chain needs update, otherwise, the later
"check_dependecies" in find_invariant_insn may fail.
although we have re-shuffle instruction 1 into 2, the later check
still using old UD info, thus
decide instruction 2 is not iv.
1: regA <- vfp + regB
2: regA <- vfp + const
my current fix is to insert those re-shuffled insn into a table named
"vfp_const_iv", then skip those
dependencies check for them as they don't have any dependencies.
LOG_LINKs have nothing to do with single use; they point from the
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 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.