llvm dev - Sep 2018 - Porting Pass to New PassManager

Is there a reason for why `-asan` and `-asan-module` can be mixed but
Function passes and Module passes with the new PM can't be mixed?

- Leo
On Thu, Sep 27, 2018 at 3:21 AM Fedor Sergeev <fedor.sergeev at azul.com>
wrote:
>
> On 09/27/2018 12:25 PM, Philip Pfaffe wrote:
>>
>> `opt < %s -passed='asan' -asan-module -S`
>
> asan-module is another ModulePass, not a commandline option.  You can't
mix that like this.
>
> I'm inclined to consider this as a deficiency of our command line
interface.
> We really should be giving some noise about newpm's  -passes overriding
any legacy-pass options.
>
> Especially since these legacy-pass options sometimes are hard to
distinguish from non-pass options.
>
> regards,
>   Fedor.
>
>
> Cheers,
> Philip
>
>>
>> doesn't  produce the same IR as
>>
>> `opt < %s -asan -asan-module -S`
>>
>> More specifically, the only thing missing seems to be the
>> `asan.module_ctor` that should get added to the global ctors list.
>> What I'm not sure of is if I'm missing something when I made
the new
>> pass or it's something in the pipeline regarding which passes run
>> first between both PMs. I could just make an AddressSanitizerModule
>> pass for the new PM, but feel like this should still work even if
>> AddressSanitizer is added in the new PM and AddressSanitizerModule is
>> added in legacy.
>>
>> - Leo
>
>

Actually I figured out how to run both a module and function pass. So
now for the test `test/Instrumentation/AddressSanitizer/basic.ll`,
both `-asan -asan-module` and
`-passes='function(asan),module(asan-module)` produce the same
instrumented code.
On Fri, Sep 28, 2018 at 12:11 PM Leonard Chan <leonardchan at google.com>
wrote:
>
> Is there a reason for why `-asan` and `-asan-module` can be mixed but
> Function passes and Module passes with the new PM can't be mixed?
>
> - Leo
> On Thu, Sep 27, 2018 at 3:21 AM Fedor Sergeev <fedor.sergeev at
azul.com> wrote:
> >
> > On 09/27/2018 12:25 PM, Philip Pfaffe wrote:
> >>
> >> `opt < %s -passed='asan' -asan-module -S`
> >
> > asan-module is another ModulePass, not a commandline option.  You
can't mix that like this.
> >
> > I'm inclined to consider this as a deficiency of our command line
interface.
> > We really should be giving some noise about newpm's  -passes
overriding any legacy-pass options.
> >
> > Especially since these legacy-pass options sometimes are hard to
distinguish from non-pass options.
> >
> > regards,
> >   Fedor.
> >
> >
> > Cheers,
> > Philip
> >
> >>
> >> doesn't  produce the same IR as
> >>
> >> `opt < %s -asan -asan-module -S`
> >>
> >> More specifically, the only thing missing seems to be the
> >> `asan.module_ctor` that should get added to the global ctors list.
> >> What I'm not sure of is if I'm missing something when I
made the new
> >> pass or it's something in the pipeline regarding which passes
run
> >> first between both PMs. I could just make an
AddressSanitizerModule
> >> pass for the new PM, but feel like this should still work even if
> >> AddressSanitizer is added in the new PM and AddressSanitizerModule
is
> >> added in legacy.
> >>
> >> - Leo
> >
> >

Its not a problem of Function vs Module.
It is a problem of New vs Legacy.

-asan and -asan-module are legacy pm.
-passes=asan is new pm.

If you implement asan-module for new pm you can use it
something like this:
   -passes=function(asan),asan-module

(exact syntax depends on how do you register the passes)

regards,
   Fedor.

On 09/28/2018 10:11 PM, Leonard Chan wrote:
> Is there a reason for why `-asan` and `-asan-module` can be mixed but
> Function passes and Module passes with the new PM can't be mixed?
>
> - Leo
> On Thu, Sep 27, 2018 at 3:21 AM Fedor Sergeev <fedor.sergeev at
azul.com> wrote:
>> On 09/27/2018 12:25 PM, Philip Pfaffe wrote:
>>> `opt < %s -passed='asan' -asan-module -S`
>> asan-module is another ModulePass, not a commandline option.  You
can't mix that like this.
>>
>> I'm inclined to consider this as a deficiency of our command line
interface.
>> We really should be giving some noise about newpm's  -passes
overriding any legacy-pass options.
>>
>> Especially since these legacy-pass options sometimes are hard to
distinguish from non-pass options.
>>
>> regards,
>>    Fedor.
>>
>>
>> Cheers,
>> Philip
>>
>>> doesn't  produce the same IR as
>>>
>>> `opt < %s -asan -asan-module -S`
>>>
>>> More specifically, the only thing missing seems to be the
>>> `asan.module_ctor` that should get added to the global ctors list.
>>> What I'm not sure of is if I'm missing something when I
made the new
>>> pass or it's something in the pipeline regarding which passes
run
>>> first between both PMs. I could just make an AddressSanitizerModule
>>> pass for the new PM, but feel like this should still work even if
>>> AddressSanitizer is added in the new PM and AddressSanitizerModule
is
>>> added in legacy.
>>>
>>> - Leo
>>

I made a patch at https://reviews.llvm.org/D52739 that I think
implements all I need for the porting. I'm able to use them with
`opt`, but still need to figure out how to use this new PM
infrastructure with clang when running `-fsanitize=address`.

- Leonard
On Fri, Sep 28, 2018 at 12:28 PM Fedor Sergeev <fedor.sergeev at azul.com>
wrote:
>
> Its not a problem of Function vs Module.
> It is a problem of New vs Legacy.
>
> -asan and -asan-module are legacy pm.
> -passes=asan is new pm.
>
> If you implement asan-module for new pm you can use it
> something like this:
>    -passes=function(asan),asan-module
>
> (exact syntax depends on how do you register the passes)
>
> regards,
>    Fedor.
>
> On 09/28/2018 10:11 PM, Leonard Chan wrote:
> > Is there a reason for why `-asan` and `-asan-module` can be mixed but
> > Function passes and Module passes with the new PM can't be mixed?
> >
> > - Leo
> > On Thu, Sep 27, 2018 at 3:21 AM Fedor Sergeev <fedor.sergeev at
azul.com> wrote:
> >> On 09/27/2018 12:25 PM, Philip Pfaffe wrote:
> >>> `opt < %s -passed='asan' -asan-module -S`
> >> asan-module is another ModulePass, not a commandline option.  You
can't mix that like this.
> >>
> >> I'm inclined to consider this as a deficiency of our command
line interface.
> >> We really should be giving some noise about newpm's  -passes
overriding any legacy-pass options.
> >>
> >> Especially since these legacy-pass options sometimes are hard to
distinguish from non-pass options.
> >>
> >> regards,
> >>    Fedor.
> >>
> >>
> >> Cheers,
> >> Philip
> >>
> >>> doesn't  produce the same IR as
> >>>
> >>> `opt < %s -asan -asan-module -S`
> >>>
> >>> More specifically, the only thing missing seems to be the
> >>> `asan.module_ctor` that should get added to the global ctors
list.
> >>> What I'm not sure of is if I'm missing something when
I made the new
> >>> pass or it's something in the pipeline regarding which
passes run
> >>> first between both PMs. I could just make an
AddressSanitizerModule
> >>> pass for the new PM, but feel like this should still work even
if
> >>> AddressSanitizer is added in the new PM and
AddressSanitizerModule is
> >>> added in legacy.
> >>>
> >>> - Leo
> >>
>