[llvm-dev] Adding a clang commandline option to change backend behaviour

[Oskar Szakinnis via llvm-dev]

Thank you all for your suggestions!

@David, thanks for the advice, I'll check MCOptions again and look into LLVMContext.
@Craig, @Aaron, great suggestion, moving the option away from CommandFlags.inc to a more appropriate file and adding an extern declaration to the corresponding header gives me more flexibility and allows me to invoke the option by using -mllvm. From my current understanding, adding a function attribute would not be sufficient, since I need to query the option unrelated to functions, e.g. as early as when the X86RegisterInfo constructor is called. As of now, I'm not aware of any mechanism within the codebase that would allow me to do so, but perhaps you can point out something.

Thanks again
Oskar

> Aaron Smith <aaron.lee.smith at gmail.com> hat am 6. Januar 2020 um 23:06 geschrieben:
> 
> 
> Define your option in the backend and declare it extern in the other
> files you want to use it in.
> 
> // X86TargetMachine.cpp
> cl::opt<bool>
>     MyOption("my new option", cl::init(true), cl::Hidden,
>                     cl::desc("Enable my new option"));
> 
> // X86SomeOtherFile.cpp
> extern cl::opt<bool> MyOption;
> if (MyOption) {
>  // do something
> }
> 
> On Mon, Jan 6, 2020 at 1:30 PM Craig Topper via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > CommandFlags.inc is only included by llc and opt. I think it mostly just sets things on TargetMachine and TargetOptions and connects them to command line options. Clang has its own code for setting up TargetMachine and TargetOptions.
> >
> > I think a lot of configuration things these days tend to be done with function attributes in IR. You can just query the function attribute wherever without any need to have a centralized option. They also probably works better with LTO since the option is stored for each function so different source files can have different settings.
> >
> > ~Craig
> >
> >
> > On Mon, Jan 6, 2020 at 1:12 PM David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> >>
> >> Mostly I've only worked with debug info - so anything that I need passed down to the backend goes into MCOptions, MCAsmInfo, and things like that.
> >>
> >> If you want to affect the way LLVM middle end optimization passes behave, that may require a different channel (might find some options on the LLVMContext? Maybe, but maybe not - perhaps those sort of parameters get passed straight to the passes in some way)
> >>
> >> On Mon, Jan 6, 2020 at 12:20 PM Oskar Szakinnis via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> >>>
> >>> Hello everyone,
> >>>
> >>> I'm currently working on a project that required me to fundamentally modify certain mechanisms of the x86 backend, as well as certain functions within PrologEpilogInserter (so my changes are not confined to a single pass - e.g. they include changes to the x86RegisterInfo constructor).
> >>> In my current solution, I have added an option within llvm/include/llvm/CodeGen/CommandFlags.inc to enable my modifications (the modifications are placed within if-conditions in multiple segments of the code).
> >>> This requires me to compile test code in two steps (first run clang with -emit-llvm, then run llc with my option enabled in the command line).
> >>>
> >>> Now I would like to be able to enable my modification through a clang command line option. What would be the canonical way to do so and which steps do I have to take? I already looked into the dev guide, but perhaps I missed something.
> >>>
> >>> I already tried using -mllvm as a workaround, but for some reason my option is not being recognized. Ultimately, I'd prefer not to rely on -mllvm anyway.
> >>>
> >>> To sum up my question: I want to be able to pass a boolean command line parameter to clang and use it within certain conditional statements within multiple files of the backend.
> >>>
> >>> Thank you for your help and let me know if my intent is unclear.
> >>>
> >>> Oskar
> >>> _______________________________________________
> >>> LLVM Developers mailing list
> >>> llvm-dev at lists.llvm.org
> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev