Tyler,
Thanks for working on this!
First, this patch contains a few things that looks like unrelated cleanup
(formatting changes and extra CHECK lines in the tests). Please separate these
out (and commit them separately).
Except, not the formatting part of this change (because it makes the lines too
long):
- /// State of the loop optimization specified by the spelling.
let Args = [EnumArgument<"Option", "OptionType",
- ["vectorize", "vectorize_width", "interleave",
"interleave_count",
- "unroll", "unroll_count"],
- ["Vectorize", "VectorizeWidth", "Interleave",
"InterleaveCount",
- "Unroll", "UnrollCount"]>,
- DefaultIntArgument<"Value", 1>];
+ ["vectorize", "vectorize_width", "interleave",
"interleave_count", "unroll", "unroll_count"],
+ ["Vectorize", "VectorizeWidth", "Interleave",
"InterleaveCount", "Unroll", "UnrollCount"]>,
+ DefaultBoolArgument<"Enabled", 0>,
+ ExprArgument<"Value", 0>];
And, regarding errors like this:
+/* expected-error {{invalid argument; expected a positive integer value}} */
#pragma clang loop interleave_count(10 / 5 - 2)
I think it is important that we provide the evaluated integer value in the
error message (it is obvious in this example, but if the numbers some from
preprocessor macros and/or template parameters, it likely won't be obvious).
Similarly, if we're given something of the wrong type (like a floating-point
value), we should provide the name of the bad type.
Thanks again,
Hal
----- Original Message -----
> From: "Tyler Nowicki" <[email protected]>
> To: "llvm cfe" <[email protected]>, "Hal Finkel" <[email protected]>,
> "Aaron Ballman" <[email protected]>,
> "Richard Smith" <[email protected]>
> Cc: "Nadav Rotem" <[email protected]>
> Sent: Friday, June 27, 2014 4:11:17 PM
> Subject: [PATCH] Support constant expressions, including non-type template
> parameters, in pragma loop hints
>
> Hi Hal, Aaron, Richard,
>
> This patch adds support for constant expressions, including non-type
> template parameters, in pragma loop hints.
>
> Support for constant expressions is done using
> ParseConstantExpression() in the pragma parser, modifying the
> LoopHintAttr to hold an Expr, and transforming the LoopHintAttr
> expression during template instantiation.
>
> Previously it was suggested that I also split the LoopHintAttr into
> an Attr for enable/disable loop hints and an Attr for loop hints
> with an expression. I gave it a try but it caused a lot of
> duplication without much of a reduction in the complexity of loop
> hint handling. I am willing to give it another look if you think it
> would be better in the long run.
>
> Tyler
>
>
>
--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
