[Lex] #pragma clang transform

[Meinersbur]

Summary

This is a series of patches that adds a new pragma for loop transformations. I hope for feedback before the LLVM DevMtg where this will be the topic of my talk. The talk will give an overview about how to add such an extension that touches all of clang's layers and would hate to give wrong advice.

The syntax is:

#pragma clang transform distribute
#pragma clang transform unroll/unrollandjam [full/partial(n)]
#pragma clang transform vectorize [width(n)]
#pragma clang transform interleave [factor(n)]

The selection is currently limited to the passes LLVM currently supports. I am working on more transformations that currently are only picked-up by Polly. The biggest difference to #pragma clang loop it allows to specify in which order the transformations are applied, which is ignored by clang's current LoopHint attribute. It is also designed a bit more carefully, e.g. vectorize and interleave are unambiguously different transformations and no question whether setting an optimization option also enables the transformations.

In the longer term, we plan to add more features such as:

• More transformations (tiling, fusion, interchange, array packing, reversal, wavefronting, peeling, splitting, space-filling curves, unswitching, collapsing, strip/strip-mining, blocking, )
• More options
• Assigning identifiers to code such that they can be referenced by transformations. (e.g. tile a loop nest, vectorize the second-to-innermost loop and parallelize the outermost).
• Non-loop transformations (code motion, versioning, ...)
• OpenMP compatibility

Regarding the latter item, we are adding loop transformation to the OpenMP specification. The next technical report presented at SC'19 will feature a tiling transformation. As such, this patch is inspired by clang's OpenMP implementation to make an integration later easier. It's not OpenMP though, in that for instance the OpenMP construct will apply tiling regardless of semantic equivalence while #pragma clang transform takes the classical compiler-hint approach in that it (by default) still does a correctness check, only
influencing the profitability heuristic.

A previous prototype that was closer to how #pragma clang loop is implemented using attributes instead of adding an additional kind of AST nodes. This showed its limitations in that it did not allow all use-cases (such as #pragma without a following statement) and its argument format can only store an array of in-source identifiers and expressions. The prototype also used the '#pragma clang loop syntax, but it proved difficult to disambiguate whether the transformations are ordered or not.

The patch is split into multiple reviews:

• [this patch] The lexer part adds annotation begin- and end-tokens to the token stream, as OpenMP does.
• D69089: The parser part parses the tokens between the annotation tokens and calls ActOn... methods of Sema which are empty in this patch. The subclasses of Transform represent the transformation to apply (e.g. "unroll by a factor of 4") and its properties ("consumes 1 loop and emits one main loop and a remainder").
• D69091: The sema part also adds the AST nodes kinds: the Stmt representing the #pragma (TransformExecutableDirective) and the clauses (TransformClause). Moreover, the AnalysisTransform component constructs a loop nest tree to which transformations are applied to such that Sema can warn about inconsistencies, e.g. there is no inner or ambiguous loops for unrollandjam.
• D69092: The codegen part uses the same AnalysisTransform to determine which loop metadata nodes to emit.
• D70572: (De-)serialization of TransformExecutableDirective and its clauses for modules and precompiled headers.
• D71447: CIndex for libclang AST traversal
• D70032: Documentation update
• Optional parts not yet ready such as completion, ASTMatcher and tooling

Thanks in advance for the review!

[ABataev]

Why not try to improve the existing #pragma clang loop rather than add a new pragma with almost the same behavior?

[hsaito]

@Meinersbur, if I remember correctly, there was an RFC discussion on this topic, right? If yes, would you post the pointer to that? I need a refresher on what has been discussed/settled in the past.

[Meinersbur]

In D69088#1713147, @ABataev wrote:

Why not try to improve the existing #pragma clang loop rather than add a new pragma with almost the same behavior?

The behavior and syntax is different. #pragma clang loop ignores the order, i.e.

#pragma clang loop unroll(enable)
#pragma clang loop distribute(enable)

and

#pragma clang loop distribute(enable)
#pragma clang loop unroll(enable)

and

#pragma clang loop unroll(enable) distribute(enable)

are the same. Changing that would be a breaking change.

Syntactically, every option is it's own transformation, e.g.

#pragma clang loop unroll(enable) distribute(enable) unroll_count(2)

could be interpreted as 3 transformations (LoopUnroll even exists twice in the pass pipeline). I prefer OpenMP's directive-with-clauses syntax, which we need to implement anyway for the OpenMP loop transformations.

In the future, I would also like to add non-loop transformation, making the loop namespace unfavorable.

[Meinersbur]

In D69088#1713623, @hsaito wrote:

@Meinersbur, if I remember correctly, there was an RFC discussion on this topic, right? If yes, would you post the pointer to that? I need a refresher on what has been discussed/settled in the past.

https://lists.llvm.org/pipermail/cfe-dev/2018-May/058141.html

[tyler.nowicki]

In D69088#1713648, @Meinersbur wrote:

In D69088#1713623, @hsaito wrote:

@Meinersbur, if I remember correctly, there was an RFC discussion on this topic, right? If yes, would you post the pointer to that? I need a refresher on what has been discussed/settled in the past.

https://lists.llvm.org/pipermail/cfe-dev/2018-May/058141.html

Sorry if this is answered in the patches but what happens if a loop has both #pragma clang loop and transform defined before it? I guess it probably shouldn't work.

Perhaps instead you could create a new option to indicate that the order should be respected.

#pragma clang loop respect_order <- optionally with (true) or (false)

That approach would avoid the inevitable conflicts of having both loop and transform pragmas on the same loop.

(Sorry if you received this twice)

[Meinersbur]

In D69088#1713831, @tyler.nowicki wrote:

In D69088#1713648, @Meinersbur wrote:

In D69088#1713623, @hsaito wrote:

@Meinersbur, if I remember correctly, there was an RFC discussion on this topic, right? If yes, would you post the pointer to that? I need a refresher on what has been discussed/settled in the past.

https://lists.llvm.org/pipermail/cfe-dev/2018-May/058141.html

Sorry if this is answered in the patches but what happens if a loop has both #pragma clang loop and transform defined before it? I guess it probably shouldn't work.

Yes, the plan was to make it an hard error. I unfortunately forgot to add that to D69091, thanks for reminding me. In the current implementation the #pragma clang loop would be applied first, but it's not intentional.

Perhaps instead you could create a new option to indicate that the order should be respected.

#pragma clang loop respect_order <- optionally with (true) or (false)

That approach would avoid the inevitable conflicts of having both loop and transform pragmas on the same loop.

There is also a syntax difference:

#pragma clang loop vectorize_width(4)

compared to

#pragma clang transform vectorize width(4)

which in a similar form is also how it is done in OpenMP:

#pragma omp simd simdlen(4)

IMHO, a respect_order option is problematic, not only because it influences parsing while being parsed. It also makes the preferable behavior clunkier to use.

[Meinersbur]

In D69088#1713831, @tyler.nowicki wrote:

That approach would avoid the inevitable conflicts of having both loop and transform pragmas on the same loop.

I fear it will give us far worse ambiguities. Consider:

#pragma clang loop unroll(enable) respect_order unrollandjam(enable) unroll_count(4)

How often does it unroll?

[ABataev]

In D69088#1713901, @Meinersbur wrote:

In D69088#1713831, @tyler.nowicki wrote:

That approach would avoid the inevitable conflicts of having both loop and transform pragmas on the same loop.

I fear it will give us far worse ambiguities. Consider:

#pragma clang loop unroll(enable) respect_order unrollandjam(enable) unroll_count(4)

How often does it unroll?

Just do not allow this form with respect_order clause.

[hsaito]

Have we established general consensus for the desire to have the flexible enough loop optimization pass ordering to accomplish the outcome of the new directive, and shared vision for the path to get there? If we are making this a general clang directive, I'd like to see the vision to get there w/o depending on polly. If this is already discussed and settled, pointer to that is appreciated so that I can learn.

Thanks,
Hideki

[Meinersbur]

In D69088#1713915, @ABataev wrote:

Just do not allow this form with respect_order clause.

What exactly would be the rules what is allowed and what isn't?

We can just not allow not mixing #pragma clang loop and #pragma clang transform.

[Meinersbur]

In D69088#1713933, @hsaito wrote:

Have we established general consensus for the desire to have the flexible enough loop optimization pass ordering to accomplish the outcome of the new directive, and shared vision for the path to get there? If we are making this a general clang directive, I'd like to see the vision to get there w/o depending on polly. If this is already discussed and settled, pointer to that is appreciated so that I can learn.

Response to the RFCs was meager. However, I got positive feedback at various conferences, including last year's DevMtg where my version for loop transformations was a technical talk.

[hsaito]

In D69088#1714019, @Meinersbur wrote:

In D69088#1713933, @hsaito wrote:

Have we established general consensus for the desire to have the flexible enough loop optimization pass ordering to accomplish the outcome of the new directive, and shared vision for the path to get there? If we are making this a general clang directive, I'd like to see the vision to get there w/o depending on polly. If this is already discussed and settled, pointer to that is appreciated so that I can learn.

Response to the RFCs was meager. However, I got positive feedback at various conferences, including last year's DevMtg where my version for loop transformations was a technical talk.

Personally, I like the intent. I don't foresee a clear (enough) path to get there. This leads to hesitation of adding a new non-experimental pragma and present it to programmers. If you call it experimental, it's easier for me to swallow.

[Meinersbur]

In D69088#1714020, @hsaito wrote:

Personally, I like the intent. I don't foresee a clear (enough) path to get there. This leads to hesitation of adding a new non-experimental pragma and present it to programmers. If you call it experimental, it's easier for me to swallow.

Is there anything more to do than mentioning as being it experimental in the (no-patch-available-yet) docs?

[Meinersbur]

In D69088#1713623, @hsaito wrote:

@Meinersbur, if I remember correctly, there was an RFC discussion on this topic, right? If yes, would you post the pointer to that? I need a refresher on what has been discussed/settled in the past.

My publications on this topic would also be useful here, available on arXiv. Here is an overview, also including previous discussions:

Loop optimization directives:

• A Proposal for Loop-Transformation Pragmas (IWOMP'18)
• User-Directed Loop-Transformations in Clang (LLVM-HPC'18)
• Design and Use of Loop-Transformation Pragmas (IWOMP'19)
• RFC: Extending #pragma clang loop (cfe-dev)
• [[ https://github.com/SOLLVE/clang/tree/pragma | Prototype implementation using #pragma clang loop and attributes ]] (GitHub)

Loop attributes metadata:

• RFC: Extending loop metadata (llvm-dev)
• D57978: Metadata for follow-up transformations

Applying loop optimizations:

• Loop Optimization Framework (LCPC'18)
• Loop Transformations in LLVM (LLVM DevMtg'18)
• Prototype implementation for applying transformations using Polly (GitHub)

[hsaito]

In D69088#1714575, @Meinersbur wrote:

In D69088#1714020, @hsaito wrote:

Personally, I like the intent. I don't foresee a clear (enough) path to get there. This leads to hesitation of adding a new non-experimental pragma and present it to programmers. If you call it experimental, it's easier for me to swallow.

Is there anything more to do than mentioning as being it experimental in the (no-patch-available-yet) docs?

If there is a precedence, just follow that. Else, how to spell an experimental clang pragma would be a good discussion topic by itself. If I need to provide a discussion starter, I'd say how about transform_experimental instead of transform. All I ask is somehow make it easier for programmers to know it is experimental so that they won't use it w/o first reading about the current state of support. I don't have a strong opinion about how to do so.

If others with stakes in loop optimizations foresee a clear enough path to get there, I won't insist this being experimental, but I would like to understand the path.

Thanks,
Hideki

[Meinersbur]

In D69088#1715038, @hsaito wrote:

If there is a precedence, just follow that. Else, how to spell an experimental clang pragma would be a good discussion topic by itself. If I need to provide a discussion starter, I'd say how about transform_experimental instead of transform. All I ask is somehow make it easier for programmers to know it is experimental so that they won't use it w/o first reading about the current state of support. I don't have a strong opinion about how to do so.

The precedences I have found are -fexperimental-pass-manager, -fexperimental-isel, std::experimental and clang-cl /openmp:experimental, Modules and a couple of features only mentioning "experimental" in their commit log.

I dislike changing the syntax syntax as it means that we will at one point break already written code or have to maintain two spellings. I'd rather just enable them with a command-line switch, such as -fexperimental-transform.

[hsaito]

In D69088#1715210, @Meinersbur wrote:

I'd rather just enable them with a command-line switch, such as -fexperimental-transform.

This direction works for me. -fexperimental-transform-pragma might be better, though.

[Meinersbur]

• Use PRAGMA_ANNOTATION
• Monorepo layout

[Meinersbur]

• Implement -f(no-)experimental-transform-pragma

[Meinersbur]

ping

[ABataev]

clang/lib/Parse/ParsePragma.cpp

3062

Add a message in this assert.

3063–3067

These asserts are covered by the very first one assert(!Tok.isAnnotation());

[Meinersbur]

• Address @ABataev's review

[Meinersbur]

ping

[rjmccall]

This is a major new language feature, and code review is probably not the right venue for reviewing it; there should be a thread on cfe-dev. My apologies if that's already been discussed and I missed it.

[greened]

In D69088#1772141, @rjmccall wrote:

This is a major new language feature, and code review is probably not the right venue for reviewing it; there should be a thread on cfe-dev. My apologies if that's already been discussed and I missed it.

I agree. I know the original RFC didn't get many responses but perhaps discussion will pick up given that patches now exist. The discussion should happen on both cfe-dev and llvm-dev because it affects both.

In particular I'd like to understand the motivation for this. Is it for experimental purposes, to aid in compiler tuning, to allow the user to override compiler decisions and/or something else?

[Meinersbur]

In D69088#1772141, @rjmccall wrote:

This is a major new language feature, and code review is probably not the right venue for reviewing it; there should be a thread on cfe-dev. My apologies if that's already been discussed and I missed it.

For some reason Phabricator did not send me an email when you submitted your comment such that I missed it. I only noticed it with @greened comment. My apologies.

I will write send an RFC to the mailing-list.

[Meinersbur]

ping

[Meinersbur]

ping

[Meinersbur]

ping

[Meinersbur]

ping

[kbarton]

@Meinersbur I missed the RFC and discussion on the cfe-dev mailing list. Could you post a link here so that it's included in the history?

I don't have any opposition to this, and it seems that you have addressed all the comments from reviewers. So, unless there was something that came up from the RFC discussion (which I doubt, since you just pinged the patch), I think this is good to land. However, I'm not really in a position to approve the patch since the implementation is well out of my domain of expertise.

[Meinersbur]

In D69088#2023114, @kbarton wrote:

@Meinersbur I missed the RFC and discussion on the cfe-dev mailing list. Could you post a link here so that it's included in the history?

See the collection of links in a previous comment: https://reviews.llvm.org/D69088#1715025

In particular, you seem to look for this: https://lists.llvm.org/pipermail/cfe-dev/2018-May/058141.html . However, there was no response to that RFC.

[Meinersbur]

ping

clang/include/clang/Basic/LangOptions.def

 LANGOPT(CUDADeviceApproxTranscendentals, 1, 0, "using approximate transcendental functions")
 LANGOPT(GPURelocatableDeviceCode, 1, 0, "generate relocatable device code")
 LANGOPT(GPUAllowDeviceInit, 1, 0, "allowing device side global init functions for HIP")
 
 LANGOPT(SYCLIsDevice      , 1, 0, "Generate code for SYCL device")
 
 LANGOPT(HIPUseNewLaunchAPI, 1, 0, "Use new kernel launching API for HIP")
 
+LANGOPT(ExperimentalTransformPragma, 1, 0, "Enable #pragma clang transform")
+
 LANGOPT(SizedDeallocation , 1, 0, "sized deallocation")
 LANGOPT(AlignedAllocation , 1, 0, "aligned allocation")
 LANGOPT(AlignedAllocationUnavailable, 1, 0, "aligned allocation functions are unavailable")
 LANGOPT(NewAlignOverride  , 32, 0, "maximum alignment guaranteed by '::operator new(size_t)'")
 LANGOPT(ConceptsTS , 1, 0, "enable C++ Extensions for Concepts")
 BENIGN_LANGOPT(ModulesCodegen , 1, 0, "Modules code generation")
 BENIGN_LANGOPT(ModulesDebugInfo , 1, 0, "Modules debug info")
 BENIGN_LANGOPT(ElideConstructors , 1, 1, "C++ copy constructor elision")

clang/include/clang/Basic/TokenKinds.def

 PRAGMA_ANNOTATION(pragma_opencl_extension)
 
 // Annotations for OpenMP pragma directives - #pragma omp ...
 // The lexer produces these so that they only take effect when the parser
 // handles #pragma omp ... directives.
 PRAGMA_ANNOTATION(pragma_openmp)
 PRAGMA_ANNOTATION(pragma_openmp_end)
 
+// Annotations for code transformation pragmas
+// #pragma clang transform ...
+PRAGMA_ANNOTATION(pragma_transform)
+PRAGMA_ANNOTATION(pragma_transform_end)
+
 // Annotations for loop pragma directives #pragma clang loop ...
 // The lexer produces these so that they only take effect when the parser
 // handles #pragma loop ... directives.
 PRAGMA_ANNOTATION(pragma_loop_hint)
 
 PRAGMA_ANNOTATION(pragma_fp)
 
 // Annotation for the attribute pragma directives - #pragma clang attribute ...

clang/include/clang/Driver/Options.td

 def fopenmp_cuda_teams_reduction_recs_num_EQ : Joined<["-"], "fopenmp-cuda-teams-reduction-recs-num=">, Group<f_Group>,
   Flags<[CC1Option, NoArgumentUnused, HelpHidden]>;
 def fopenmp_optimistic_collapse : Flag<["-"], "fopenmp-optimistic-collapse">, Group<f_Group>,
   Flags<[CC1Option, NoArgumentUnused, HelpHidden]>;
 def fno_openmp_optimistic_collapse : Flag<["-"], "fno-openmp-optimistic-collapse">, Group<f_Group>,
   Flags<[NoArgumentUnused, HelpHidden]>;
 def static_openmp: Flag<["-"], "static-openmp">,
   HelpText<"Use the static host OpenMP runtime while linking.">;
+def fexperimental_transform_pragma : Flag<["-"], "fexperimental-transform-pragma">, Group<f_Group>,
+  Flags<[CC1Option, HelpHidden]>, HelpText<"Parse #pragma clang transform directives.">;
+def fno_experimental_transform_pragma : Flag<["-"], "fno-experimental-transform-pragma">, Group<f_Group>,
+  Flags<[CC1Option, HelpHidden]>, HelpText<"Disable #pragma clang transform directives.">;
 def fno_optimize_sibling_calls : Flag<["-"], "fno-optimize-sibling-calls">, Group<f_Group>;
 def foptimize_sibling_calls : Flag<["-"], "foptimize-sibling-calls">, Group<f_Group>;
 def fno_escaping_block_tail_calls : Flag<["-"], "fno-escaping-block-tail-calls">, Group<f_Group>, Flags<[CC1Option]>;
 def fescaping_block_tail_calls : Flag<["-"], "fescaping-block-tail-calls">, Group<f_Group>;
 def force__cpusubtype__ALL : Flag<["-"], "force_cpusubtype_ALL">;
 def force__flat__namespace : Flag<["-"], "force_flat_namespace">;
 def force__load : Separate<["-"], "force_load">;
 def force_addr : Joined<["-"], "fforce-addr">, Group<clang_ignored_f_Group>;

clang/include/clang/Parse/Parser.h

class Parser : public CodeCompletionHandler {
   std::unique_ptr<PragmaHandler> NoUnrollHintHandler;
   std::unique_ptr<PragmaHandler> UnrollAndJamHintHandler;
   std::unique_ptr<PragmaHandler> NoUnrollAndJamHintHandler;
   std::unique_ptr<PragmaHandler> FPHandler;
   std::unique_ptr<PragmaHandler> STDCFENVHandler;
   std::unique_ptr<PragmaHandler> STDCCXLIMITHandler;
   std::unique_ptr<PragmaHandler> STDCUnknownHandler;
   std::unique_ptr<PragmaHandler> AttributePragmaHandler;
+  std::unique_ptr<PragmaHandler> TransformHandler;
 
   std::unique_ptr<CommentHandler> CommentSemaHandler;
 
   /// Whether the '>' token acts as an operator or not. This will be
   /// true except when we are parsing an expression within a C++
   /// template argument list, where the '>' closes the template
   /// argument list.
   bool GreaterThanIsOperator;

clang/lib/Frontend/CompilerInvocation.cpp

if (Arg *A = Args.getLastArg(OPT_fclang_abi_compat_EQ)) {
     } else if (Ver != "latest") {
       Diags.Report(diag::err_drv_invalid_value)
           << A->getAsString(Args) << A->getValue();
     }
   }
 
   Opts.CompleteMemberPointers = Args.hasArg(OPT_fcomplete_member_pointers);
   Opts.BuildingPCHWithObjectFile = Args.hasArg(OPT_building_pch_with_obj);
+
+  // Enable or disable support for #pragma clang transform.
+  Opts.ExperimentalTransformPragma =
+      Args.hasFlag(options::OPT_fexperimental_transform_pragma,
+                   options::OPT_fno_experimental_transform_pragma, false);
 }
 
 static bool isStrictlyPreprocessorAction(frontend::ActionKind Action) {
   switch (Action) {
   case frontend::ASTDeclList:
   case frontend::ASTDump:
   case frontend::ASTPrint:
   case frontend::ASTView:

clang/lib/Parse/ParsePragma.cpp

PragmaAttributeHandler(AttributeFactory &AttrFactory)
       : PragmaHandler("attribute"), AttributesForPragmaAttribute(AttrFactory) {}
   void HandlePragma(Preprocessor &PP, PragmaIntroducer Introducer,
                     Token &FirstToken) override;
 
   /// A pool of attributes that were parsed in \#pragma clang attribute.
   ParsedAttributes AttributesForPragmaAttribute;
 };
 
+struct PragmaTransformHandler : public PragmaHandler {
+  PragmaTransformHandler() : PragmaHandler("transform") {}
+  void HandlePragma(Preprocessor &PP, PragmaIntroducer Introducer,
+                    Token &FirstToken) override;
+};
+
 }  // end namespace
 
 void Parser::initializePragmaHandlers() {
   AlignHandler = std::make_unique<PragmaAlignHandler>();
   PP.AddPragmaHandler(AlignHandler.get());
 
   GCCVisibilityHandler = std::make_unique<PragmaGCCVisibilityHandler>();
   PP.AddPragmaHandler("GCC", GCCVisibilityHandler.get());
void Parser::initializePragmaHandlers() {
   PP.AddPragmaHandler(NoUnrollAndJamHintHandler.get());
 
   FPHandler = std::make_unique<PragmaFPHandler>();
   PP.AddPragmaHandler("clang", FPHandler.get());
 
   AttributePragmaHandler =
       std::make_unique<PragmaAttributeHandler>(AttrFactory);
   PP.AddPragmaHandler("clang", AttributePragmaHandler.get());
+
+  if (getLangOpts().ExperimentalTransformPragma) {
+    TransformHandler = std::make_unique<PragmaTransformHandler>();
+    PP.AddPragmaHandler("clang", TransformHandler.get());
+  }
 }
 
 void Parser::resetPragmaHandlers() {
   // Remove the pragma handlers we installed.
   PP.RemovePragmaHandler(AlignHandler.get());
   AlignHandler.reset();
   PP.RemovePragmaHandler("GCC", GCCVisibilityHandler.get());
   GCCVisibilityHandler.reset();
void Parser::resetPragmaHandlers() {
   PP.RemovePragmaHandler(NoUnrollAndJamHintHandler.get());
   NoUnrollAndJamHintHandler.reset();
 
   PP.RemovePragmaHandler("clang", FPHandler.get());
   FPHandler.reset();
 
   PP.RemovePragmaHandler("clang", AttributePragmaHandler.get());
   AttributePragmaHandler.reset();
+
+  if (getLangOpts().ExperimentalTransformPragma) {
+    PP.RemovePragmaHandler("clang", TransformHandler.get());
+    TransformHandler.reset();
+  }
 }
 
 /// Handle the annotation token produced for #pragma unused(...)
 ///
 /// Each annot_pragma_unused is followed by the argument token so e.g.
 /// "#pragma unused(x,y)" becomes:
 /// annot_pragma_unused 'x' annot_pragma_unused 'y'
 void Parser::HandlePragmaUnused() {
void PragmaUnrollHintHandler::HandlePragma(Preprocessor &PP,
   TokenArray[0].setKind(tok::annot_pragma_loop_hint);
   TokenArray[0].setLocation(PragmaName.getLocation());
   TokenArray[0].setAnnotationEndLoc(PragmaName.getLocation());
   TokenArray[0].setAnnotationValue(static_cast<void *>(Info));
   PP.EnterTokenStream(std::move(TokenArray), 1,
                       /*DisableMacroExpansion=*/false, /*IsReinject=*/false);
 }
 
+/// Handle
+///   #pragma clang transform ...
+void PragmaTransformHandler::HandlePragma(Preprocessor &PP,
+                                          PragmaIntroducer Introducer,
+                                          Token &FirstTok) {
+  // "clang" token is not passed
+  // "transform" is FirstTok
+  // Everything up until tok::eod (or tok::eof) is wrapped between
+  // tok::annot_pragma_transform and tok::annot_pragma_transform_end, and
+  // pushed-back into the token stream. The tok::eod/eof is consumed as well:
+  //
+  // Token stream before:
+  //   FirstTok:"transform" | <trans> [clauses..] eod   ...
+  //
+  // Token stream after :
+  //            "transform"   <trans> [clauses..] eod | ...
+  // After pushing the annotation tokens:
+  //
+  // | annot_pragma_transform <trans> [clauses..] annot_pragma_transform_end ...
+  //
+  // The symbol | is before the next token returned by PP.Lex()
+  SmallVector<Token, 16> PragmaToks;
+
+  Token StartTok;
+  StartTok.startToken();
+  StartTok.setKind(tok::annot_pragma_transform);
+  StartTok.setLocation(FirstTok.getLocation());
+  PragmaToks.push_back(StartTok);
+
+  SourceLocation EodLoc = FirstTok.getLocation();
+  while (true) {
+    Token Tok;
+    PP.Lex(Tok);
+    assert(!Tok.isAnnotation() &&
+           "It should not be possible to nest annotations");
+
+    if (Tok.is(tok::eod) || Tok.is(tok::eof)) {
+      EodLoc = Tok.getLocation();
+      break;
+    }
+
+    PragmaToks.push_back(Tok);
+  }
+
+  Token EndTok;
+  EndTok.startToken();
+  EndTok.setKind(tok::annot_pragma_transform_end);
+  EndTok.setLocation(EodLoc);
+  PragmaToks.push_back(EndTok);
+
+  // Copy tokens for the preprocessor to own and free.
+  auto Toks = std::make_unique<Token[]>(PragmaToks.size());
+  std::copy(PragmaToks.begin(), PragmaToks.end(), Toks.get());
+
+  // Handle in parser
+  PP.EnterTokenStream(std::move(Toks), PragmaToks.size(),
+                      /*DisableMacroExpansion=*/false, /*IsReinject=*/false);
+}
+
 /// Handle the Microsoft \#pragma intrinsic extension.
 ///
 /// The syntax is:
 /// \code
 ///  #pragma intrinsic(memset)
 ///  #pragma intrinsic(strlen, memcpy)
 /// \endcode
 ///

clang/test/Parser/pragma-no-transform.cpp

+// RUN: %clang_cc1 -std=c++11 -fno-experimental-transform-pragma -Wall -verify %s
+
+void pragma_transform(int *List, int Length) {
+/* expected-warning@+1 {{unknown pragma ignored}} */
+#pragma clang transform unroll partial(4)
+  for (int i = 0; i < Length; i+=1)
+      List[i] = i;
+}
+