This is the mail archive of the
mailing list for the GCC project.
Re: Patch: Add #pragma ivdep support to the ME and C FE
- From: Richard Biener <rguenther at suse dot de>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Tobias Burnus <tobias dot burnus at physik dot fu-berlin dot de>, Frederic Riss <frederic dot riss at gmail dot com>, gcc-patches at gcc dot gnu dot org, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Wed, 23 Oct 2013 14:32:42 +0200 (CEST)
- Subject: Re: Patch: Add #pragma ivdep support to the ME and C FE
- Authentication-results: sourceware.org; auth=none
- References: <20131016142449 dot GA2553 at physik dot fu-berlin dot de> <alpine dot LNX dot 2 dot 00 dot 1310170959210 dot 11149 at zhemvz dot fhfr dot qr> <20131017083608 dot GC30970 at tucnak dot zalov dot cz> <52658A0A dot 7060809 at net-b 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
> 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)
possibly doing after it
for (... stmts ...)
if (gimple_call_internal_p (stmt)
&& gimple_call_internal_fn (stmt) == IFN_ANNOTATE)
warning ("ignoring ...");
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 ...