what is official way to determine if we are running lto 2nd stage?

Project Infrastructure LLVM Dev List Archives
1

Hi,

I want to enable some target-specific functionality only if current
build is 2nd LTO stage (i.e. optimizer called from plugin). What is
best and recommended way to do it?

2

Hi,

3

Hi,

In LTO we have AsmParser that process inline assembler instructions to
MCInst and I want to fix some inline assembler in order to conform its
rules (do not start with non-identifier and so on) because asm syntax
of our backend allows some incompatible patterns. In order to do this
I am adding IR-level target-specific pass. But those fixes shall not
be applied when there is no AsmParser later to process them. So I want
to switch this pass off if we are not in 2nd lto stage.

I think, I can make target-specific option and make user to supply it
whenever he wants to run 2nd lto stage, but this is ugly.

Can I somehow ask, say, about whole string of options and then parse
it to match "lto" from here?

4

This is not clear to me: how should this be different for LTO than for a non-LTO compile?

Also, if you’re only fixing the inline ASM, why doing it as an IR-level pass instead of MachineFunctionPass?

5

Hi,

This is really basic block level pass. It is no difference what is
level, problem is the same.

After fixing for asm parser, assembler syntax is no more valid for
backend, without processing with asm parser.

May be it will be solution to process inline asm on insn printer level
to remove syntax fixes. But just switch it off without lto will make
compiler do less job

P.S. sorry for dup, maillist CC lost on first sent.

6

Hi,

This is really basic block level pass. It is no difference what is
level, problem is the same.

Can you clarify what you mean? If you have a MachineFunction pass, it’ll run in the backend only.
I don’t understand why you would need to distinguish between LTO or no-LTO here.

After fixing for asm parser, assembler syntax is no more valid for
backend, without processing with asm parser.

My understanding of Inline ASM is that it is supposed to be opaque to the backend till you reach MC.
So I don’t understand this sentence "no more valid for backend, without processing with asm parser”.

Sorry if my answers don’t make sense to you, I may still be missing a key part of your problem.

7

Note that it is no problem to add target specific IR passes. Just override the relevant functions in your targets TargetPassConfig (TargetPassConfig::addIRPasses() or any of the more specific functions there).

8

Hi,

Imagine that your backend has valid asm instruction written like this:

"%x mnem %y, %z"

And user puts it as inline assembler:

__asm__ ("%x mnem %y, %z");

It can not be parsed with current llvm asm parser, because it starts
with % (moreover it has mnemonic in second place)

Say you written pass, that makes it "mnem %x, %y, %z".

Now this guy can be parsed, but can not be encoded by gas. You simply
havent that instruction in you assembler. For LTO it isn't a problem:
you can make arbitrary MCInst from everything that comes into
ParseInstruction. But it is problem for regular scenario where wrong
asm will be printed and then passed to gas.

So I want to apply this on 2nd lto stage where AsmParser is inevitable
and to not apply in non-LTO cases.

9

OK, from what you are describing, it does not seem a LTO vs non-LTO, but integrated-ASM vs non-integrated-ASM, right?

10

Hi,

This is possible interpretation. But really only use-case where we
need AsmParser now is lto case. So for me it is more about lto vs
non-lto, because in non-lto cases we can simply output any assembler
and call gas via custom Toolchain in clang, whereas in lto we need to
be asmparser-compatible.