Re: [patch] Fix PR tree-optimization/49471

[Richard Guenther <richard dot guenther at gmail dot com>]

2011/7/30 Zdenek Dvorak <rakdver@kam.mff.cuni.cz>:
> Hi,
>
>> > This patch fixes the build failure of cactusADM and dealII spec2006
>> > benchmarks when autopar is enabled.
>> > (for powerpc they fail only when -m32 is additionally enabled)
>> >
>> > The problem originated in canonicalize_loop_ivs, where we iterate the
>> > header's phis in order to base all
>> > the induction variables on a single control variable.
>> > We use the largest precision of the loop's ivs in order to determine the
>> > type of the control variable.
>> >
>> > Since iterating the loop's phis takes into account not only the loop's
>> > ivs, but also reduction variables,
>> > we got precision values like 80 for x86, or 128 for ppc.
>> > The compilers failed to create proper types for these sizes
>> > (respectively).
>> >
>> > The proper behavior for determining the control variable's type is to take
>> > into account only the loop's ivs,
>> > which is what this patch does.
>> >
>> > Bootstrap and testsuite pass successfully (as autopar is not enabled by
>> > default).
>> > No new regressions when the testsuite is run with autopar enabled.
>> > No new regressions for the run of spec2006 with autopar enabled,
>> >
>> > cactusADM and dealII benchmarks now pass successfully with autopar on
>> > powerpc and x86.
>> >
>> > Thanks to Zdenek who helped me figure out the failure/fix.
>> > OK for trunk?
>>
>> It'll collide with Sebastians patch in that area. ?I suggested a
>> INTEGRAL_TYPE_P check instead of the simple_iv one, it
>> should be cheaper. ?Zdenek, do you think it will be "incorrect"
>> in some cases?
>
> well, it does not make much sense -- reductions of integral type would
> be taken into consideration for determining the size of the canonical
> variable. ?However, it is not a big issue (the choice of the type is more
> or less arbitrary, as long as the number of iterations fits into it; selecting
> the type based on another existing iv is just to avoid unnecessary extensions),

Hm, ok.  Shouldn't we then simply choose a signed type that can hold
niter based on the fact that we know this IV won't overflow?  Choosing
the biggest of all IVs precision looks indeed odd if we just need to count
from zero to niter.

Richard.

> Zdenek
>
>> Thanks,
>> Richard.
>>
>> > Thanks,
>> > Razya
>> >
>> > ChangeLog:
>> >
>> > ? PR tree-optimization/49471
>> > ? * tree-vect-loop-manip.c (canonicalize_loop_ivs): Add condition to
>> > ? ignore reduction variables when iterating the loop header's phis.
>> >
>> >
>> >
>