#pragma GCC unroll support

[Richard Biener]

On Mon, Dec 22, 2014 at 10:13 PM, Mike Stump <mikestump@comcast.net> wrote:
> So, I have a rough cut of a new feature to add pragma GCC unroll support to gcc.  It is safe wrt the test suite and code-gen, but there are some corners that I need help or suggestions on how to round off nicely.
>
> Things to think about, can we put this in even if we have TODO support for C++ template support?  I think that is only 2-5 lines away from completion, but one needs to play peak-a-boo with some data (the unroll count) and I wanted to let pt fingers decide where to hide the data.  See RANGE_FOR_IVDEP for how I want to do it.
>
> Can I increase the size of all annotations to 3 from 2?  It seemed safer, easier than trying to subdivide it.

Sure.  But I'd make the 2nd operand optional (thus use NULL_TREE,
not integer_zero_node for existing builds).

You also need to check that 'unroll' fits in the target integer_type_node
(consider AVR!) and otherwise diagnose it.

The 'unroll' member in struct loop should be unsigned (or you need to
document what negative values are supposed to mean).  It also
should be smaller than int (struct loop may be heavily used), possibly
short or even (un)signed char(?).

@@ -341,7 +341,10 @@ tree_estimate_loop_size (struct loop *lo
              if (likely_eliminated || likely_eliminated_last)
                size->last_iteration_eliminated_by_peeling += num;
            }
-         if ((size->overall * 3 / 2 - size->eliminated_by_peeling
+         /* A loop that we want to unroll is never too large.  */
+         if (loop->unroll > 0)
+           ;

but if we end up unrolling more than loop->unroll then it may be too large?
That is this check should be in the caller, not here.

I think you miss updating copy_loop_info (and places where we don't
use that but still copy loops somehow).

> I didn’t engineer ivdeps and unroll together.  Does it sound reasonable to allow both to be used at the same time on the same loop?  If so, I can add the two other cases, presently I just handle one of them then the loop.

Yes.

> Fortran support is left to the fortran people, if they want to do it.  I wired it up tantalizingly close for them to complete.
>
> See ICK in the code.  I was unsure how to resolve that code.
>
> Does unroll 8 mean that the loop is repeated 8 times?

Up to you to define - what do other compilers do for #pragma unroll 0
and #pragma unroll 1?

> Can I turn on peeling in try_peel_loop by simply wanted to do it for 1 loop?

?

> I support using -1 for a directive that says, don’t peel, don’t unroll.  As a UI issue, I think this is wrong.  I want to to be either 0 or 1, those two seem better.  But, not sure which is the right one of the two.  Which number says, don’t unroll, I’m smarter than you think.

#pragma unroll 0

or

#pragma nounroll

what do other compilers do?

> If we have a loop that we know can only be unroll 7 times, and the user says unroll 8, should we unroll it 7 times?  Presently I do.  The other option, is to ignore the directive when we know it is non-sensicle.

Yes, unroll 7 times.

> Yes, I’m aware that this isn’t the right phase for this, but such are business cycles.  It would not go in until we reenter stage 1.  I see no value in trying to squeeze it in past stage 1.

The interesting parts are mostly frontend stuff, the middle-end bits look
fine apart from the above issues (it feels like you need to add too many
checks for loop->unroll in the peeler...)

Richard.