This is an archive of the discontinued LLVM Phabricator instance.

[OpenMP][OMPIRBuilder] Mirgrate getName from clang to OMPIRBuilder
ClosedPublic

Authored by jsjodin on Nov 9 2022, 9:16 AM.

Details

Summary

This change moves the getName function from clang and moves the separator class
members from CGOpenMPRuntime into OpenMPIRBuilder.

There is a question if we want this kind of state in the OpenMPIRBuilder, there
are other parameters that could be class members like IsEmbedded (IsDevice),
IsTargetCodegen etc. These are currently derived from the CodeGenModule class in clang.
Moving more of the code generation into OpenMPIRBuilder requires knowledge of these parameters,
which have so far been passed in as arguments to the functions, but the number of parameters
might become too many to pass around all the time. There is a case where these parameters should
be made part of the OMPIRBuilder, and used in CGOpenMPRuntime.

Diff Detail

Event Timeline

jsjodin created this revision.Nov 9 2022, 9:16 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 9 2022, 9:16 AM
jsjodin requested review of this revision.Nov 9 2022, 9:16 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 9 2022, 9:16 AM

Maybe we want a configuration object that is populated once by the user and passed to the OMPIRBuilder to cluster all such configurations, e.g., device, embedded, etc. We can also choose separators based on that internally.

llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
182

Rename to something meaningful.

Maybe we want a configuration object that is populated once by the user and passed to the OMPIRBuilder to cluster all such configurations, e.g., device, embedded, etc. We can also choose separators based on that internally.

Yes, I think that sounds good. Formalizing the attributes that affect codgen (in a configuration object) should make the code easier to understand/maintain. I can start working on a patch to add the configuration object.

Maybe we want a configuration object that is populated once by the user and passed to the OMPIRBuilder to cluster all such configurations, e.g., device, embedded, etc. We can also choose separators based on that internally.

Yes, I think that sounds good. Formalizing the attributes that affect codgen (in a configuration object) should make the code easier to understand/maintain. I can start working on a patch to add the configuration object.

After looking a bit more closely into this, there are a few factors to consider. There are uses of the OpenMPIRBuilder, for example in mlir with the OpenACC frontend (it uses the OpenMPIRBuilder for some reason) and in the OMP optimizer, where I do not know if the configuration makes sense. The OffloadEntriesInfoManager is dependent on these flags, which means that the configuration must be available somehow.
I am working on creating the new class OpenMPIRBuilderConfig (or maybe OpenMPIRBuilderContext). The config can be passed in to both the OpenMPIRBuilder and OffloadEntriesInfoManager, constructors. The config can be made optional either by using a pointer which could be null so that the uses of OpenMPIRBuilder in mlir and opt do not have to create a config, howerver using functions that require it would cause an error (segfault). Alternatively we could make the various flags in the Config into llvm::Optional<Flag> so that the configuration can be done flexibly, and use of any functions in the Builder would give a nicer error if the value is not set. It will also make the code look more uniform with "Config." instead of "Config->".

I'm currently working on using llvm::Optional for the various attiibutes, since that is more flexible. Let me know if you have any other ideas how to handle this.

I'm currently working on using llvm::Optional for the various attiibutes, since that is more flexible. Let me know if you have any other ideas how to handle this.

Optional is good, for the fields or the config object. Alternatively defaults as we can derive them would be OK too. A mix might be good, if we can derive a sensible default, we use it, if not, it's Optional and None.

I'm currently working on using llvm::Optional for the various attiibutes, since that is more flexible. Let me know if you have any other ideas how to handle this.

Optional is good, for the fields or the config object. Alternatively defaults as we can derive them would be OK too. A mix might be good, if we can derive a sensible default, we use it, if not, it's Optional and None.

Just for reference the patch is here: https://reviews.llvm.org/D138220

jdoerfert added inline comments.Nov 18 2022, 1:53 PM
llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
160

This will move into the config object now, right? Can we also avoid the user telling us the string refs and instead determining them on the rest of the config?

jsjodin updated this revision to Diff 477257.Nov 22 2022, 11:02 AM

Use the new config class. Perhaps the separators could be inferred from isTargetCodgen, but keeping them explicit for now.

jsjodin added inline comments.Nov 22 2022, 11:06 AM
llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
160

This will move into the config object now, right? Can we also avoid the user telling us the string refs and instead determining them on the rest of the config?

160

This will move into the config object now, right? Can we also avoid the user telling us the string refs and instead determining them on the rest of the config?

Yes, I updated the patch just to see that everything builds okay, but we should be able to infer the separators.

182

Rename to something meaningful.

Forgot to address this, will fix together with inferring separators.

jsjodin marked an inline comment as not done.Nov 22 2022, 11:06 AM
jsjodin marked an inline comment as not done.
jdoerfert added inline comments.Nov 22 2022, 12:59 PM
clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
895

Why do we need to pass them here at all? What's the second argument for? Doesn't it effectively tell us what the separators are?

I just wanted to point you at https://reviews.llvm.org/D136743 (BuiltinTypeDeclBuilder). They use the Rust Builder Pattern. If the configuration of the OpenMPIRBuilder becomes to complex, maybe there is space for something similar.

I just wanted to point you at https://reviews.llvm.org/D136743 (BuiltinTypeDeclBuilder). They use the Rust Builder Pattern. If the configuration of the OpenMPIRBuilder becomes to complex, maybe there is space for something similar.

Will be kept in mind. Thx!

jsjodin updated this revision to Diff 477533.Nov 23 2022, 9:26 AM

Make firstSeparator() and separator() return the correct default values when the optional values are not set. This will allow overriding the default, and will avoid inconsistencies in the case IsTargetCodegen is modified in the config. Change name of getName to something more descriptive. Maybe getPlatformSpecificName is better than createPlatformSpecificName, feedback is welcome.

jdoerfert accepted this revision.Nov 23 2022, 10:46 AM

LG, thx

This revision is now accepted and ready to land.Nov 23 2022, 10:46 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 24 2022, 7:16 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript