This is an archive of the discontinued LLVM Phabricator instance.

[OPENMP] CodeGen - 'omp for' with dynamic schedule kinds
ClosedPublic

Authored by amusman on Jan 23 2015, 2:16 AM.

Details

Summary

Please review codegen implementation of the ‘omp for’ loop with dynamic schedule kinds.

Diff Detail

Repository
rL LLVM

Event Timeline

amusman updated this revision to Diff 18653.Jan 23 2015, 2:16 AM
amusman retitled this revision from to [OPENMP] CodeGen - 'omp for' with dynamic schedule kinds.
amusman updated this object.
amusman edited the test plan for this revision. (Show Details)
amusman added a subscriber: Unknown Object (MLST).
rjmccall edited edge metadata.Feb 4 2015, 1:26 AM

Generally looks good. A couple organization suggestions to eliminate some of the code duplication.

lib/CodeGen/CGOpenMPRuntime.cpp
426 ↗(On Diff #18653)

Your only caller here pattern-matches on the integer size and signedness so that it can pass the right enum value down just so that this code can immediately switch out to cases that are identical except for slight differences in integer size and signedness. This is kindof silly.

You don't *have* to shove everything through this one method; you can have a CreateDispatchRuntimeFunction method or something that returns the appropriate function from a named family for a given integer size and signedness. Or you could be slightly less type-safe and just have CreateRuntimeFunction take (defaultable) arguments that pick the right function from a family, like how LLVM overloaded intrinsics work.

Please do something like that instead of having all this redundancy, though.

lib/CodeGen/CGOpenMPRuntime.h
383 ↗(On Diff #18653)

These are not useful documentation. You can just leave off the comment about CGF. For Loc, there's probably an existing discussion about the purpose of the source locations you can refer to.

394 ↗(On Diff #18653)

Why does this specifically return a CallInst* instead of just a Value*?

lib/CodeGen/CGStmtOpenMP.cpp
591 ↗(On Diff #18653)

Just have EmitOMPForNext do this conversion and return an i1.

610 ↗(On Diff #18653)

Is there no init otherwise? Seems like something that should be asserted.

amusman updated this revision to Diff 21726.Mar 11 2015, 8:31 AM
amusman edited edge metadata.

Hi John,

Thank you for review! I've fixed all the issues.
I think a similar refactoring can be done for OMPRTL__kmpc_for_static_init_*, I can do it in follow-up commit.

Best regards,
Alexander

Okay, great, thank you. LGTM.

This revision was automatically updated to reflect the committed changes.