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

[Oskar Szakinnis via llvm-dev]

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

[David Blaikie via llvm-dev]

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)

_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

[Craig Topper via llvm-dev]

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

[Aaron Smith via llvm-dev]

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

[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.l...@gmail.com> hat am 6. Januar 2020 um 23:06 geschrieben:

[Craig Topper via llvm-dev]

I don't think I can help make the attribute work without know what you're changing in the X86RegisterInfo constructor?

~Craig

[Oskar Szakinnis via llvm-dev]

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....@gmail.com> hat am 9. Januar 2020 um 23:31 geschrieben:

[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