This is an archive of the discontinued LLVM Phabricator instance.

[OpenMP] Add OpenMP variant extension to keep the unmangled name
Needs ReviewPublic

Authored by jhuber6 on Mar 30 2022, 1:40 PM.

Details

Summary

The OpenMP variant clause current ensures unique function identifiers by
mangling the name with $ompvariant.... This patch adds an extension to
prevent this by stripping off the mangling during code generation. Doing
this will conflict with the other symbols in the module, but it will
allow us to overload the names of existing symbols if their definitions
are allowed to be dropped. This is most useful for overloading the
meaning of math functions without changing the symbol so they can still
be identified by LLVM.

Diff Detail

Event Timeline

jhuber6 created this revision.Mar 30 2022, 1:40 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 30 2022, 1:40 PM
jhuber6 requested review of this revision.Mar 30 2022, 1:40 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptMar 30 2022, 1:40 PM

The test currently fails because we don't do the stripping when we emit the precompiled header, it will simply be imported using the mangled version and it will not have in the original input info associated with it. I will need to figure out where we emit the PCH definitions and also demangle it there.

jhuber6 updated this revision to Diff 419567.Mar 31 2022, 1:56 PM

Updating to use an attribute instead to get around the loss of the identifier info when using PCH. Unfortunately this still causes problems when using PCH.

jhuber6 updated this revision to Diff 420604.Apr 5 2022, 12:29 PM

Updating to stop erroring if a function with the same mangled error exists, but is never emitted.

There is no documentation of the extension and attribute. See also below.

clang/lib/CodeGen/CodeGenModule.cpp
1459

Check OpenMP in the lang opts.

3063

This looks like you now disable the diagnostic for pretty much everything, no?

jhuber6 marked an inline comment as done.Apr 5 2022, 12:40 PM
jhuber6 added inline comments.
clang/lib/CodeGen/CodeGenModule.cpp
3063

This should only get called if we plan to emit this global, if the global has the attribute stating that it should not be mangled we're basically just asserting that its associated non-variant declaration should not be found. So even if we hit a name mangling conflict, as long as we haven't tried to emit that global we should be fine. I can add a test for this.

jhuber6 updated this revision to Diff 420608.Apr 5 2022, 12:51 PM

Make suggested changes.

jdoerfert added inline comments.Apr 5 2022, 12:56 PM
clang/lib/CodeGen/CodeGenModule.cpp
3063

We only put things in this set for a special OpenMP case, correct?
The error condition below triggers only if something is in this set.

So all non-openmp codes will never see this diagnostic, or what am I missing?