This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] PR 62173, re-shuffle insns for RTL loop invariant hoisting
- From: Jiong Wang <wong dot kwongyuan dot tools at gmail dot com>
- To: Kenneth Zadeck <zadeck at naturalbridge 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 11:20:14 +0000
- 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>
2014-12-19 15:21 GMT+00:00 Kenneth Zadeck <zadeck@naturalbridge.com>:
>
> 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
>>>>> _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.
>
>