This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: fragile test case ivopt_infer_2.c
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: "Bin.Cheng" <amker dot cheng at gmail dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, tom at codesourcery dot com
- Date: Thu, 20 Jun 2013 10:43:00 +0200
- Subject: Re: fragile test case ivopt_infer_2.c
- References: <CAHFci28EcT0DfHTj=OvMq6ccQpC-P_CZoq=r_yUU=71OUNJF1Q at mail dot gmail dot com> <CAFiYyc11=j4+dPSwxpJy=kcaY2SxQvhdjBmtXRvMe+ZXHt1-Rw at mail dot gmail dot com> <CAHFci28fGKK+_F56sjCnCKvw+d5wbTw=oDNMGvXbqRw9=HqAWA at mail dot gmail dot com> <CAFiYyc18ae2-ax9U9rZ-eYf2WqzsNmR=YEA2Z_0DFQeLOmFhDw at mail dot gmail dot com> <CAHFci2_dmg+X1bmw3Gp2F=17-FQazjRgkO-hGX_vRAZCGmmCvA at mail dot gmail dot com>
On Wed, Jun 19, 2013 at 4:30 PM, Bin.Cheng <amker.cheng@gmail.com> wrote:
> On Wed, Jun 19, 2013 at 8:33 PM, Richard Biener
> <richard.guenther@gmail.com> wrote:
>> On Wed, Jun 19, 2013 at 12:35 PM, Bin.Cheng <amker.cheng@gmail.com> wrote:
>>> On Wed, Jun 19, 2013 at 4:43 PM, Richard Biener
>>> <richard.guenther@gmail.com> wrote:
>>>> On Wed, Jun 19, 2013 at 10:04 AM, Bin.Cheng <amker.cheng@gmail.com> wrote:
>>>>> Hi,
>>>>> For test case gcc.dg/tree-ssa/ivopt_inter_2.c
>>>>>
>>>>> #ifndef TYPE
>>>>> #define TYPE char*
>>>>> #endif
>>>>>
>>>>> extern char a[];
>>>>>
>>>>> /* Can not infer loop iteration from array -- exit test can not be replaced. */
>>>>> void foo (unsigned int i_width, TYPE dst)
>>>>> {
>>>>> unsigned long long i = 0;
>>>>> unsigned long long j = 0;
>>>>> for ( ; j < i_width; )
>>>>> {
>>>>> *dst = a[i];
>>>>> dst++;
>>>>> i += 2;
>>>>> j += 1;
>>>>> }
>>>>> }
>>>>>
>>>>> /* { dg-final { scan-tree-dump-times "Replacing" 0 "ivopts"} } */
>>>>> /* { dg-final { cleanup-tree-dump "ivopts" } } */
>>>>>
>>>>> It checks whether the test is eliminated by address iv candidate,
>>>>> which is fragile.
>>>>> Giving the ivopt dump file :
>>>>>
>>>>> foo (unsigned int i_width, char * dst)
>>>>> {
>>>>> long long unsigned int j;
>>>>> long long unsigned int i;
>>>>> long long unsigned int _4;
>>>>> char _9;
>>>>> long long unsigned int _18;
>>>>>
>>>>> <bb 2>:
>>>>> _18 = (long long unsigned int) i_width_7(D);
>>>>> if (_18 != 0)
>>>>> goto <bb 3>;
>>>>> else
>>>>> goto <bb 7>;
>>>>>
>>>>> <bb 3>:
>>>>>
>>>>> <bb 4>:
>>>>> # j_21 = PHI <j_13(5), 0(3)>
>>>>> _9 = MEM[symbol: a, index: j_21, step: 2, offset: 0B];
>>>>> MEM[base: dst_5(D), index: j_21, offset: 0B] = _9;
>>>>> j_13 = j_21 + 1;
>>>>> if (j_13 < _18)
>>>>> goto <bb 5>;
>>>>> else
>>>>> goto <bb 6>;
>>>>>
>>>>> <bb 5>:
>>>>> goto <bb 4>;
>>>>>
>>>>> <bb 6>:
>>>>>
>>>>> <bb 7>:
>>>>> return;
>>>>> }
>>>>>
>>>>> It's possible to have "if (j_13 < _18)" eliminated into "if (j_13 !=
>>>>> _18)", and the case would fail because of dump message "Replacing exit
>>>>> test: if (j_13 < _18)"
>>>>>
>>>>> Same story for ivopt_mult_3.c
>>>>>
>>>>> Any idea how it should be handled?
>>>>
>>>> Probably by checking for the real issue - I suppose at some point
>>>> the number of iterations was infered to be zero or one.
>>>>
> If I was right, this case is intended to test the exit test "j_13 <
> _18" cannot be replaced by using the array address, i.e., something
> like "a_XXX != YYY". Why it is fragile is because the exit test might
> be replaced by "j_13 != _18". In this case, the use is eliminated by a
> candidate has same iv->base/step as the use itself.
>
> It's possible to dump additional information like "if (j_13 < _18)
> eliminated into if (j_13 !=> _18) because of candidate with same
> base/step" , thus we can check this valid elimination in test case.
> Any advice?
Yes, more precise dumping could help this case, too. Or scan that
the exit test does not look like &a <> ...
Richard.
> Hi Tom, since you adapted the test case, I am ccing you for some comments too.
>
> Thanks.
> bin