This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, rtl-optimization]: Fix PR 45223, RTL PRE GCSE pass hoists trapping insn out of loop
On Thu, Aug 12, 2010 at 12:01 PM, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Tue, Aug 10, 2010 at 6:11 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>
>>> Attached patch fixes wrong hoisting of trapping insns out from the
>>> loop. ?As commented in the original PR [1], the problem is in PRE GCSE
>>> pass that does not look if the moved instruction can trap. ?The
>>> original problem reliably triggers on targets, where modulo is a
>>> single HW insn (as in case of moxie-elf target), but the problem can
>>> also be shown on x86_64-pc-linux-gnu with slightly modified testcase
>>> [2].
>>>
>>> 2010-08-07 ?Uros Bizjak ?<ubizjak@gmail.com>
>>>
>>> ? ? ? ?PR rtl-optimization/45223
>>> ? ? ? ?* gcse.c (compute_hash_table_work): Skip insns that may trap when
>>> ? ? ? ?building hash table.
>>>
>>> The patch was bootstrapped and regression tested on
>>> x86_64-pc-linux-gnu {,-m32} on gcc-4_5 branch. I have also checked
>>> that patched gcc produces correct asm for moxie and for modified FP
>>> case. In the modified FP case, --ffast-math still hoists FP division
>>> out of the loop (allowed by may_trap_p predicate).
>>>
>>> H.J. will check the performance effect of the patch on the SPEC, but
>>> --ffast-math compilation seems to be unaffected.
>>>
>>
>> Here are the ration of before and after on Intel Core i7. Gzip slowed
>> down by 10 to 20%.
>>
>> 32bit: -O2:
>>
>> 164.gzip ? ? ? ? ? ? ? ? ? ? ? ? -23.8895%
>
> Ouch.
>
> So, patch retraced, see also comment in [1]:
>
> "The problem is that this is hard to fix without pessimizing the common case."
>
> Please also note, that due to your results, it looks that RTL
> optimizer optimizes gzip in the wrong way. Tree optimizer left the
> division inside the loop, but RTL optimizer hoisted the division out.
> Probably the right thing to do, but this can't be proved (otherwise
> tree optimizer would hoist the division).
>
> There is nothing that can be done here. If we fix RTL optimizer, there
> will be severe degradation in integer code. FP is OK with
> --ffast-math.
>
> I have added some CCs that would eventually be interested in this issue.
>
> [1]: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38819#c20
The fix is to teach LIM to do conditional invariant motion.
Richard.