Re: [tuples] Tuplify tree-parloops.c

[Zdenek Dvorak <rakdver at kam dot mff dot cuni dot cz>]

Hi,

>   One issue is in create_parallel_loop, where trunk has:
>   for (phi = phi_nodes (ex_bb); phi; phi = PHI_CHAIN (phi))
>     {
>       res = PHI_RESULT (phi);
>       gcc_assert (!is_gimple_reg (phi));
>   Testing whether a PHI is not a gimple reg doesn't make any sense,
>   in the patch below I had to comment that out, as PHIs are
>   gimple, while is_gimple_reg is called on trees.  Unfortunately
>   gcc_assert (!is_gimple_reg (res)); which might make some sense
>   triggers e.g. on the above testcase.

the intention definitely was !is_gimple_reg (res).  The check was there
before support for reductions was added, and because in its mistaken
form it cannot trigger, it remained there.  It probably can be removed
safely.

> 2) for -O2 -ftree-parallelize-loops=4
> unsigned int ub[16], uc[16];
> unsigned int foo (void)
> {
>   int i;
>   unsigned int udiff = 2;
>   for (i = 0; i < 16; i++)
>     udiff += ub[i] - uc[i];
>   return udiff;
> }
>   a *loopfn* function is created and emitted, but the
>   bb with GOMP_parallel_{start,end} is immediately
>   optimized out, as the loop number of iterations
>   is constant small.  Shouldn't tree-parloops.c
>   just avoid the whole optimization if it obviously
>   only makes the code larger?

Yes; more generally, there should be some sane heuristics deciding
whether to parallelize a loop or not (at the moment, the code just tries
to parallelize as much as possible).

Sorry for all the problems with the pass -- when I wrote it, I was
under impression that there are people out there interested in working
on autoparallelization, but discouraged by the technical details.  So
I wrote the pass that we have now, made it sort of work, and expected
that someone else will take care of the remaining 90% of work :-(

Zdenek