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

[Craig Topper via llvm-dev]

You could add a MachineFunction argument
to getFramePtr(), getStackRegister() accessors and implement your logic.
Then replace all direct references to the members with calls to the
accessors instead. Not sure if you want to change that much code though.

~Craig


On Thu, Jan 9, 2020 at 3:07 PM Oskar Szakinnis <oskar at szakinnis.de> wrote:

> I'm assigning different registers (X86::RBP, X86::RSP etc.) to the
> StackPtr and FramePtr global variables, depending on my option. This is the
> only place in the code where I can not access a MachineFunction or
> MachineBasicBlock object to get the Attribute. If I can work around this
> issue, implementing my option as a function attribute should be a nice
> solution.
>
> Thank you.
> Oskar
>
> Craig Topper <craig.topper at gmail.com> hat am 9. Januar 2020 um 23:31
> geschrieben:
>
> I don't think I can help make the attribute work without know what you're
> changing in the X86RegisterInfo constructor?
>
> ~Craig
>
>
> On Thu, Jan 9, 2020 at 1:19 PM Oskar Szakinnis < oskar at szakinnis.de>
> wrote:
>
> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200109/a58c40ae/attachment.html>