[llvm-dev] what is official way to determine if we are running lto 2nd stage?
Mehdi Amini via llvm-dev
llvm-dev at lists.llvm.org
Mon Sep 12 09:52:47 PDT 2016
> On Sep 12, 2016, at 9:26 AM, Konstantin Vladimirov <konstantin.vladimirov at gmail.com> wrote:
>
> 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.
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?
—
Mehdi
>
> 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?
>
> ---
> With best regards, Konstantin
>
> On Mon, Sep 12, 2016 at 6:17 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>> Hi,
>>
>>
>>> On Sep 12, 2016, at 1:26 AM, Konstantin Vladimirov via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>>
>>> 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?
>>
>> There is none. We can setup a different optimizer pass pipeline for LTO, but the target specific part (i.e. the backend) isn’t supposed to behave differently.
>>
>> This is an issue in general with LTO where options from the command line (like -fno-builtins, or -fveclib=xxxx) are not correctly propagated to LTO.
>>
>> What kind of behavior do you want to enable exactly?
>>
>> —
>> Mehdi
>>
More information about the llvm-dev
mailing list