[PATCH, rtl-optimization]: Fix PR 45223, RTL PRE GCSE pass hoists trapping insn out of loop

[Uros Bizjak]

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