Improving autogenerated names of OpenMP outlined functions

Hey all,

As it currently stands Clang’s OpenMP CodeGen assigns the same name to all OpenMP outlined functions (“.omp_outlined.”). This is customizable targets, but it’s still completely static, which leads to a meaningless dot + running index being appended to all but the first outlined function (“.omp_outlined…150”). This stems from LLVM’s ValueSymbolTable::makeUniqueName machinery.

I was wondering whether it would be considered a nice readability improvement to pass the enclosing function’s name as a parameter to CGOpenMPRuntime::getOutlinedHelperName (and perhaps also CGOpenMPTaskOutlinedRegionInfo::getHelperName), such that it could be appended to the generated identifier. There will still be conflicts when there are multiple outlined regions in the same function, but at least it will be much more pleasant to inspect the IR.

What do you think?

1 Like

I’ll take a look.

For posterity, I’ve submitted a patch here: ⚙ D140722 [OpenMP] Prefix outlined and reduction func names with original func's name.
But it does not update test outputs yet since I’ve had trouble with it (some tests’ auto-update invocation modifies the output even without my changes, which makes some things hard to verify in terms of signal-to-noise).

I think in general that’s something I would find quite useful when looking at the IR.

One thing I wonder though: What does that mean for size? If you think of heavily templated code, the function names can become quite large. So I would assume that for certain codes this may lead to quite some increases. Any chance you have looked into this already, or someone more knowledgeable than me can comment on that?

Hello, This could also ease performance monitoring & analysis here (at Linaro).

There was also a previous discussion (with a quite similar patch) about this here: Verbose outlining name

Please let me know if I can do something to help one of these patches land. Like trying to update clang tests if that is still what is missing.


I think that other than the question of the runtime tests in openmp/libomptarget/tests, the patch is ready to land.