This is an archive of the discontinued LLVM Phabricator instance.

[llvm-exegesis] Cross compile all enabled targets
ClosedPublic

Authored by reames on Sep 1 2022, 1:18 PM.

Details

Summary

llvm-exegesis is rather odd in the LLVM ecosystem in code is selectively compiled based on the native machine. LLVM is cross compiler by default, so this stands out as odd. It's also less then helpful when working on code for a target other than your native dev environment.

This change only changes the build setup. A later change will enable -march support to allow actual benchmarking under e.g. simulators in a cross compilation environment.

This is mostly cmake foo and my cmake knowledge is pretty much non-existent. Please don't hesitate to suggest cleaner ways of doing something.

Diff Detail

Event Timeline

reames created this revision.Sep 1 2022, 1:18 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 1 2022, 1:18 PM
reames requested review of this revision.Sep 1 2022, 1:18 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 1 2022, 1:18 PM

I'm not really qualified to comment on the CMake but this sounds conceptually fine apart from my comment on initialization.

llvm/tools/llvm-exegesis/llvm-exegesis.cpp
301–304

I think building all targets makes sens so that you can run an llvm-exegesis compiled on (say) X86 on AArch64. However at runtime we should only need to initialize the native target as we're going to jit compile and execute only for the host anyway.

Does this affect which tests we can run for each target? For x86 at least we split the jit/runtime tests off into subfolders from the analysis-only tests so we could at least test analysis on builds that didn't have PFM.

reames added a comment.Sep 2 2022, 7:49 AM

Does this affect which tests we can run for each target? For x86 at least we split the jit/runtime tests off into subfolders from the analysis-only tests so we could at least test analysis on builds that didn't have PFM.

At the moment, no, it should not. It does run the target initialization code for all targets now, but that shouldn't be a visible change in behavior.

Thank you for pointing out the analysis tests being separated for x86, I hadn't noticed that. Getting those enabled on all targets is likely a reasonable initial goal for the next change or two.

My eventual plan is to enable testing of the code gen in a target independent manner, and have only the benchmark execution be restricted to native target. (Well, even then I want to support cross builds, but step by step.)

llvm/tools/llvm-exegesis/llvm-exegesis.cpp
301–304

My eventual goal for this is to be able to exercise the jitting part in a cross compilation environment. So, initializing all targets will be necessary.

For this particular patch, I need the All variants to check linkage. Without them, you can skip compiling a target specific library and not notice. If you really want, I can remove them and do just the compile step in this patch, but I don't really see why.

courbet added inline comments.Sep 2 2022, 7:55 AM
llvm/tools/llvm-exegesis/llvm-exegesis.cpp
301–304

I see, SG.

LGTM as a first step - any other comments?

LGTM as far as I'm concerned.

RKSimon accepted this revision.Sep 9 2022, 7:56 AM
This revision is now accepted and ready to land.Sep 9 2022, 7:56 AM
This revision was automatically updated to reflect the committed changes.

After landing this, I got a couple dozen build bot failure notices. A large fraction of them are warnings in unrelated files - I'm guessing the cmake change confused incremental bots - but at least one looks potentially relevant. Specifically, a polly bot (https://lab.llvm.org/buildbot#builders/56/builds/3201) is failing to link in the ARM target. I don't have a good theory on what might be happening, and can't (yet) reproduce.

Maybe missing AllTargetsDisassemblers? But not sure why that would only show up on that specific buildbot.

Maybe missing AllTargetsDisassemblers? But not sure why that would only show up on that specific buildbot.

That's my guess too. I'm going to land it as a speculative fix and see what the bots do.

It looks like disassembly is only initialized on one path, and that's still using the native calls. So if we didn't have the disassembler linked in, we'd see an error like this. No idea why we apparently getting a different link set in this case..

thakis added a subscriber: thakis.Sep 9 2022, 11:58 AM

FWIW, lli also uses this pattern I think.

FWIW, lli also uses this pattern I think.

I don't follow. LLI doesn't appear to have any target dependent code.

FWIW, lli also uses this pattern I think.

I don't follow. LLI doesn't appear to have any target dependent code.

I mean that it also depends on native.

Unrelatedly, the "native" target in llvm-exegesis gets initialized due to the LLVM_EXEGESIS_INITIALIZE_NATIVE_TARGET=Initialize${LLVM_EXEGESIS_NATIVE_ARCH}ExegesisTarget in llvm/tools/llvm-exegesis/CMakeLists.txt. How do the non-native targets get initialized?

FWIW, lli also uses this pattern I think.

I don't follow. LLI doesn't appear to have any target dependent code.

I mean that it also depends on native.

Unrelatedly, the "native" target in llvm-exegesis gets initialized due to the LLVM_EXEGESIS_INITIALIZE_NATIVE_TARGET=Initialize${LLVM_EXEGESIS_NATIVE_ARCH}ExegesisTarget in llvm/tools/llvm-exegesis/CMakeLists.txt. How do the non-native targets get initialized?

In tree? They don't. See D133605