Hi,

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
|   |-<<<NULL>>>
|   |-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.. ?

paul

Attachment: ivdep.diff
Description: ivdep.diff

_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to