llvm dev - Sep 2016 - what is official way to determine if we are running lto 2nd stage?

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?

---
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
>

> 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
>>

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.

---
WIth best regards, Konstantin


On Mon, Sep 12, 2016 at 8:52 PM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>
>> 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
>>>
>