Fixed a bug with codegen of variables with array types specified in 'copyprivate' clause of 'single' directive.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Generally looks good.
lib/CodeGen/CGOpenMPRuntime.cpp | ||
---|---|---|
991 ↗ | (On Diff #23477) | Same. Although maybe you should just have a typedef for this? |
lib/CodeGen/CGOpenMPRuntime.h | ||
362 ↗ | (On Diff #23477) | You can just leave these parameter names there without commenting them out. Should SingleOpGen also be a llvm::function_ref? |
lib/CodeGen/CGStmtOpenMP.cpp | ||
117 ↗ | (On Diff #23477) | Is there a reason why this is back-to-front instead of front-to-back? In C++, arrays are generally initialized front-to-back, so that when destruction goes back-to-front it happens in reverse order of construction. |
162 ↗ | (On Diff #23477) | If this is an initialization expression, please don't call it an assignment expression. If it's an assignment expression, checking for CXXConstructExpr is not going to work. |
173 ↗ | (On Diff #23477) | It's called "RunCleanupsScope", but that part of the comment doesn't add much anyway. I'd say something like "Clean up any temporaries needed by the assignment expression." |
973 ↗ | (On Diff #23477) | You don't need the "()->void", so unless you find it helpful, it's best to leave it off. |
John, thanks for the review!
lib/CodeGen/CGOpenMPRuntime.h | ||
---|---|---|
362 ↗ | (On Diff #23477) | I think I'd better create a corresponding method in CodeGenFunction and call it instead of passing function reference as an argument. The same function is used in many places in CodeGenFunction and in CGOpenMPRuntime. |
lib/CodeGen/CGStmtOpenMP.cpp | ||
117 ↗ | (On Diff #23477) | I'll rework this |
162 ↗ | (On Diff #23477) | Ok, renamed to Init |
173 ↗ | (On Diff #23477) | Changed to "Clean up any temporaries needed by the initialization" |
973 ↗ | (On Diff #23477) | Removed. |
Thank you. Unfortunately, the assignment loop is now wrong — you're copying indexes 1 to N instead of 0 to N-1.
lib/CodeGen/CGStmtOpenMP.cpp | ||
---|---|---|
99 ↗ | (On Diff #23581) | Can these actually be different? It looks like you're decomposing the same array type. I figured you were just doing that to get the type adjustment on DestBegin right. That's fine and basically harmless; LLVM will be able to delete any unused operations you do (if it's a VLA type) pretty easily. You could also reasonably just enhance emitArrayLength to do the type adjustment to multiple pointers at once; 2 is pretty common for exactly this kind of purpose. Or you could just bitcast DestBegin to the resulting type of SrcBegin and let LLVM figure it out. |
119 ↗ | (On Diff #23581) | You're now shifting the address *forward*, and you need to do this after the element copy. That is, you should be doing the element copy from SrcElementCurrent to DestElementCurrent, and you should probably rename DestElement/SrcElement to DestElementNext/SrcElementNext. |
Fixed copy procedure, now copying from 0 to N-1 instead of from 1 to N. Array begin for source arrays now is a bitcast from the pointer to array to pointer of single element type.