This is an archive of the discontinued LLVM Phabricator instance.

[OPENMP] Fixed codegen for arrays in 'copyprivate' clause.
ClosedPublic

Authored by ABataev on Apr 9 2015, 5:16 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

ABataev updated this revision to Diff 23477.Apr 9 2015, 5:16 AM
ABataev retitled this revision from to [OPENMP] Fixed codegen for arrays in 'copyprivate' clause..
ABataev updated this object.
ABataev edited the test plan for this revision. (Show Details)
ABataev added a subscriber: Unknown Object (MLST).
rjmccall edited edge metadata.Apr 9 2015, 2:14 PM

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.

ABataev updated this revision to Diff 23581.Apr 10 2015, 1:50 AM
ABataev edited edge metadata.

Update after review

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.

ABataev updated this revision to Diff 23673.Apr 13 2015, 6:17 AM

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.

Thank you. Two minor notes and LGTM.

lib/CodeGen/CGStmtOpenMP.cpp
101 ↗(On Diff #23673)

I just noticed that this comment is not correct: you are checking for the zero-element case. I don't know if that's intentional.

125 ↗(On Diff #23673)

Please rename these to DestElementNext and SrcElementNext.

This revision was automatically updated to reflect the committed changes.