Skip to content

Add support for LLVM 19 and 20 (not CI tested)#13

Merged
TimHeldmann merged 6 commits intotudasc:develfrom
sebastiankreutzer:feat/llvm20_support
May 2, 2025
Merged

Add support for LLVM 19 and 20 (not CI tested)#13
TimHeldmann merged 6 commits intotudasc:develfrom
sebastiankreutzer:feat/llvm20_support

Conversation

@sebastiankreutzer
Copy link
Member

This patch adds support the newest version of LLVM. This is not tested in the CI yet and versions 19 and 20 are therefore not marked as supported.
Instead of giving an error, CMake now only prints a warning, if an unsupported version is detected.

@sebastiankreutzer
Copy link
Member Author

Interesting, my local GCC and Clang builds where happy. Good thing we have the CI!

@sebastiankreutzer
Copy link
Member Author

The last fixups re-add the template specifier where it's definitely needed (at least for older GCC versions), i.e. in front of function template invocations with dependent parameters. Took a few tries, but this should work for all versions now.

Copy link
Member

@TimHeldmann TimHeldmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.
It is a bit unlucky we have to resort to more and more version specific code.
But I think it is still to little to be a problem.

Comment on lines +243 to +248
const auto& [has, data] = node->template checkAndGet<PiraOneData>();
if (has) {
data->setNumberOfStatements(numStmts);
data->setHasBody(hasBody);
data->setDominantRuntime(dominantRuntime);
data->setComesFromCube(inPrevProfile);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a formatting error or correction?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a correction. I touched the file at some point so it was auto-formatted.
I think I reverted that particular change, so the content is the same.
I would just leave this bit of formatting in because I think clang-format will complain otherwise.
Does this sound ok?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, leave it in.

Comment on lines +39 to +40
MCGLogger::instance().getErrConsole()->warn("Could not create: {}, the Metadata is unknown in you application",
s);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer to have the error in one single line, instead of having only the formatting parameter in a new line.

Suggested change
MCGLogger::instance().getErrConsole()->warn("Could not create: {}, the Metadata is unknown in you application",
s);
MCGLogger::instance().getErrConsole()->warn(
"Could not create: {}, the Metadata is unknown in you application", s);

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm inclined to agree. Unfortunately clang-format does not and automatically changes it back to the original version 😄

@jplehr
Copy link
Member

jplehr commented Apr 4, 2025

Looks good to me.

It is a bit unlucky we have to resort to more and more version specific code.

But I think it is still to little to be a problem.

Agreed! Also, that's what you need to do when you do not have a stable API. And I still prefer this over using the (more stable) C interface.

If this increases more substantially, we should reflect on whether we care enough and if we want to add a wrapper layer.

jplehr
jplehr previously requested changes Apr 4, 2025
Copy link
Member

@jplehr jplehr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please run a git-clang-format again

}

auto nmd = new T(args...);
this->template addMetaData(nmd);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would think this is a change that is not related to the ability to use newer llvm versions. Am I missing something?
Will this break some GCC compatibility with older versions or so?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is related. Using the template keyword results in the following:

/home/sebastian/git/MetaCG-Gitlab/graph/include/CgNode.h:109:20: error: a template argument list is expected after a name prefixed by the template keyword [-Wmissing-template-arg-list-after-template-kw]
  109 |     this->template addMetaData(nmd);

This works in previous LLVM and GCC versions, but is not standard compliant. Since LLVM 19 (?) this is handled more strictly and results in the error shown above.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this is enabling the compilation with Clang 19 and beyond?
Don't want to block it, just trying to understand as I always thought that this is about getting the API calls right, not something else.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's both - enabling the CGCollector to work with Clang 19+ and compiling the project as a whole with thise Clang versions.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this particular change with the template keyword related to enable CGCollector to work with Clang 19+? That's the bit that I do not understand.
I can see how this enables to compile CGCollector with Clang 19+, but not how this impacts to use Clang19+ as a library.

@sebastiankreutzer
Copy link
Member Author

I think I addressed all the feedback and re-formatted the sources. Could you have another look, @jplehr and @TimHeldmann ?
Thanks!

Copy link
Member

@jplehr jplehr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some nits. I'll leave it with @TimHeldmann to accept.

const auto fileEntry = fullSrcLoc.getFileEntry();
if (!fileEntry) {
return result;
std::string fileNameStr = "";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this can remain at the original position.

Comment on lines +243 to +248
const auto& [has, data] = node->template checkAndGet<PiraOneData>();
if (has) {
data->setNumberOfStatements(numStmts);
data->setHasBody(hasBody);
data->setDominantRuntime(dominantRuntime);
data->setComesFromCube(inPrevProfile);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, leave it in.

@jplehr jplehr dismissed their stale review April 29, 2025 16:11

No longer valid.

@TimHeldmann TimHeldmann merged commit 9c22690 into tudasc:devel May 2, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants