llvm-cpufeatures: get TargetMachine from the MachineModuleInfoWrapperPass pass #44005
Conversation
…Pass pass This is usually only supposed to be accessible to a MachineModulePass, but we can trick llvm to give us access to the TargetMachine here too. Also hack in a sysimg check also, so that the compile result is ensured to be compatible with the loaded image too (we disable loading of the sysimg when emitting a new compile).
| return PreservedAnalyses::all(); | ||
| } | ||
|
|
||
| extern "C" JL_DLLEXPORT ::llvm::PassPluginLibraryInfo | ||
| llvmGetPassPluginInfo() { |
There was a problem hiding this comment.
We should move that out to a different file, since we will need to add all the other NewPM to this as well.
There was a problem hiding this comment.
You have all the other NewPM changes, right? So I will leave this up to you to move.
There was a problem hiding this comment.
There are already other passes that support the NewPM, but sure I can do that.
| @@ -0,0 +1,24 @@ | |||
| ; RUNx: opt --mtriple=`llvm-config --host-target` -enable-new-pm=1 --load-pass-plugin=libjulia-codegen%shlibext -passes='require<machine-module>,CPUFeatures' -S %s | FileCheck %s --check-prefixes=CHECK,CHECK-any | |||
There was a problem hiding this comment.
require<machine-module> needs a LLVm patch right?
There was a problem hiding this comment.
yes, right now it this is disabled, with the x
|
x-ref #43085 (comment) as context |
|
How does this interact with multiversioning? Shouldn't we be looking at the features that are annotated in the function attribute rather than the target machine? |
|
This is the fallback code, when there are no target-features set. |
|
Should the same approach be used for the Float16 PR? |
This is usually only supposed to be accessible to a MachineModulePass,
but we can trick llvm to give us access to the TargetMachine here too.
Also hack in a sysimg check also, so that the compile result is ensured
to be compatible with the loaded image too (we disable loading of the
sysimg when emitting a new compile).