------- Comment #32 from rguenther at suse dot de 2009-12-14 12:27 ------- Subject: Re: [4.4/4.5 Regression] 50% performance regression
On Mon, 14 Dec 2009, matz at gcc dot gnu dot org wrote: > ------- Comment #26 from matz at gcc dot gnu dot org 2009-12-14 04:55 ------- > And if I fix this problem (so that only one reference to *n_9) remains > I hit the problem that the fortran frontend emits the computation of countm1 > after the loop bound test. No pass is moving code in front of that test as > this is potentially a regression (more evaluations in out-of-bound case). > > And if I fix _that_ I hit the problem of the fix for PR38819. PRE won't move > the division at all, because it could trap :-/ If I disable this I get back > the 4.3 performance. Well. VRP should mark divisions as non-trapping if possible. I see (after fixing the FRE issue): # iftmp.12_8 = PHI <-1(30), 1(12)> D.1588_67 = iftmp.12_8 * D.1529_119; D.1589_68 = (character(kind=4)) D.1588_67; countm1.6_69 = D.1583_64 / D.1589_68; with D.1529_119: [2, +INF] iftmp.12_8: [1, 1] D.1588_67: [2, +INF] D.1589_68: [2, 2147483647] countm1.6_69: [0, 2147483647] so as D.1589_68 is never -1 or zero the division doesn't trap. Now it's easy to mark the stmt in VRP this way but non-trivial to keep track of it in the SCCVN IL. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
