[RFC] #pragma ivdep


The attached patch implements support for #pragma ivdep in clang. The ivdep is represented in the AST using AttributedStmt as follows:

-AttributedStmt 0x5003538 <line:37:11, line:39:5>
>-IVDepAttr 0x5003520 <line:37:11>
`-ForStmt 0x50034e0 <line:38:3, line:39:5>
  >-BinaryOperator 0x50033d8 <line:38:8, col:12> 'int' '='
  > >-DeclRefExpr 0x5003390 <col:8> 'int' lvalue Var 0x50030e0 'i' 'int'
  > `-IntegerLiteral 0x50033b8 <col:12> 'int' 0
  >-BinaryOperator 0x5003460 <col:15, col:19> 'int' '<'
  > >-ImplicitCastExpr 0x5003448 <col:15> 'int' <LValueToRValue>
  > > `-DeclRefExpr 0x5003400 <col:15> 'int' lvalue Var 0x50030e0 'i' 'int'
  > `-IntegerLiteral 0x5003428 <col:19> 'int' 10
  >-UnaryOperator 0x50034b0 <col:23, col:25> 'int' prefix '++'
  > `-DeclRefExpr 0x5003488 <col:25> 'int' lvalue Var 0x50030e0 'i' 'int'
  `-NullStmt 0x50034d0 <line:39:5>

Code generation is handled by a new helper class CGLoopMetadata and a custom IRBuilder inserter CGBuilderInserter which can annotate instructions as they're inserted.

The code generation is actually not correct. Right now any instruction with mayReadOrWriteMemory() inside a ivdep loop will get the llvm.mem.parallel_loop_access metadata. This is not correct in general as discussed here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-March/060096.html

I was hoping someone with experience with clang codegen could suggest a good way to decide when to attach the llvm.mem metadata based on the requirements described in the llvmdev thread.. ?


ivdep.diff (23.1 KB)

Sorry, I intended to send this to cfe-commits. Please ignore.