This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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:
> OpenMPv4's "omp simd" wording, see bottom of the email at

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.

+   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 ...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]