Re: Patch: Add #pragma ivdep support to the ME and C FE

[Richard Biener <rguenther at suse dot de>]

On Mon, 21 Oct 2013, Tobias Burnus wrote:

> Dear all,
> 
> attached is a new version of the patch. Changes:
> * "#pragma GCC ivdep" instead of "#pragma ivdep"
> * Corrections to the error message in c-parser.c and a test case for it
> * New wording in the .texi and examples
> 
> I am still not completely happy with the wording ? and I am open for
> suggestions. In the example, I played safe and mention k < -m and k >=m; even
> if k >= 0 probably works.
> 
> I also didn't know how to best state the reason for requiring a condition.
> (Internal reason: The annotation is attached to the condition - thus, it has
> to be present. External reason: For vectorization, there shouldn't be a
> branching in the body of the loop and without a condition in either the "for"
> header or in its body, one has an endless loop.)
> 
> Do you have suggestions for a better wording? If not, is the patch okay for
> the trunk?
> Built and regtested (C only). [An all-language bootstrap + regtesting is
> underway.]
> 
> 
> Crossrefs: C review comments:
> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00803.html
> OpenMPv4's "omp simd" wording, see bottom of the email at
> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01194.html

I don't like that you change flow_loops_find.  Please instead amend
tree-cfg.c:execute_build_cfg and do after loop_optimizer_init sth like

  FOR_EACH_LOOP (li, loop, 0)
    if (loop->latch)
      ...

possibly doing after it

  FOR_EACH_BB (bb)
    for (... stmts ...)
      if (gimple_call_internal_p (stmt)
          && gimple_call_internal_fn (stmt) == IFN_ANNOTATE)
        {
          warning ("ignoring ...");
          remove it
        }

you can of course factor this out into a function in cfgloop.c.
This whole ANNOTATE stuff is only to carry information from the frontend
through gimplification and until loops are first built.

+/* ANNOTATE_EXPR.
+   Operand 0 is the expression.  ....
+   Operand 1 is the annotation id, FIXME */
+DEFTREECODE (ANNOTATE_EXPR, "annotate_expr", tcc_expression, 1)

FIXME?  Btw, not using a tree operand here is somewhat of a premature
optimization I think ...

Thanks,
Richard.