[llvm-dev] How to build a target-specific LLVM pipeline from within the middle-end

Anna Welker via llvm-dev llvm-dev at lists.llvm.org
Wed Mar 3 01:58:56 PST 2021


Hi Arthur,

thank you so much for your reply.
Doing it the same way as SampleProfileProbePass works like a charm. I 
can't believe I did not come up with trying this variation myself, it is 
a much simpler solution than some of my attempts.

Many thanks again,
Anna

On 02.03.21 20:30, Arthur Eubanks wrote:
> You may need a TargetMachine available when constructing the pass. See 
> SampleProfileProbePass in PassRegistry.def, or most of the passes 
> added in AMDGPUTargetMachine::registerPassBuilderCallbacks().
> As for how the TargetMachine is created, you could look at how opt 
> does it in opt.cpp.
>
> On Tue, Mar 2, 2021 at 1:26 AM Anna Sophia Welker via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     Hello experts,
>
>     I am trying to build an LLVM pass that can make predictions about
>     the benefits of certain transformations by exploring them, i.e.,
>     sending the respective code sections 'ahead in time' and comparing
>     the outcome if this or that choice is made.
>
>     To my understanding, because of how the pass pipeline is set up,
>     this does require to build an entirely new pipeline (or at least
>     parts of it), to which I pass the module I create from the code I
>     want to examine.
>     I haven't really found any documentation on how the pass pipeline
>     is stitched together, so everything I know about how to do it
>     comes from reading code present in LLVM. Specifically, I've been
>     looking at EmitAssemblyHelper::EmitAssemblyWithNewPassManager in
>     clang's BackendUtil, as I expect the run my pass would be used in
>     to be started from there, and I want to exactly copy what happens
>     to the real code.
>
>     What I have achieved so far:
>     I have imitated the creation of the AnalysisManagers and have the
>     PassBuilder pass information like PTO and PGOOpt to the
>     constructor of my pass, so when the pass is run in the middle-end
>     I can build a new PassBuilder from that information, register all
>     the AnalysisManagers and build a pipeline (using
>     buildPerModuleDefaultPipeline). As the old PassManager structure
>     allows it, I can even hand over a complete CodeGen pipeline to
>     said constructor. So my pass can run the module it creates through
>     the middle-end passes all the way to code generation in the
>     backend with no issues.
>
>     My problem:
>     The middle-end run that I am getting is a 'generic' one, it does
>     not exhibit the characteristics that I expect to see for the
>     concrete architecture I specify on the command line. E.g., it is
>     using a plain TTI instead of the target's TTI, so for my partial
>     code vectorization does not at all do what it would do for the
>     normal run. Which kind of defeats the whole point of the exploration.
>     I have identified the issue to be the TargetMachine, which seems
>     to be responsible for any target-specific adaptations in the
>     middle-end. From my understanding, if it is set to nullptr, you
>     get a generic run like I do, if it isn't, you should get a run
>     fine-tuned for the architecture you're looking at. The problem is,
>     what is the proper way to acquire a TargetMachine?
>     The copy-constructor of the class has been deleted, so I cannot
>     simply hand it over to my pass like I do for the other
>     information. In BackendUtil, the TargetMachine is constructed as a
>     singleton from a long range of option information, some of it
>     clang options. From trying and failing I gather that I can not
>     include clang headers in my llvm pass, so I don't know how to even
>     pass all the required options to my pass if I were to build the
>     machine on my own from scratch, which does not feel like the right
>     thing to do anyway. I have tried passing the whole original
>     PassBuilder to my pass, which works fine, and then taking the
>     TargetMachine from there when creating my new PassBuilder (I added
>     a function getTargetMachine() to the class for testing purposes).
>     All I get is a nullptr.
>
>     Can anyone give me a hint on what I am doing wrong, or how to do
>     it right? Or is this simply something that LLVM is not supposed to
>     allow, period?
>     I do realise I could just manually add the passes I need for the
>     architecture I'm looking at, but the idea was to make the tool
>     usable for any architecture by just doing exactly what the 'parent
>     run' is doing. Only, everything is so nicely encapsulated that I'm
>     struggeling to access the information necessary in the place I
>     need it.
>
>     Looking forward to any feedback or suggestions!
>
>     Many thanks,
>     Anna Welker
>
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
-- 
Anna Sophia Welker
s9aawelk at stud.uni-saarland.de
+49 152 33901367

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210303/047aa47a/attachment-0001.html>


More information about the llvm-dev mailing list