llvm dev - Sep 2018 - Porting Pass to New PassManager

>
> `opt < %s -passed='asan' -asan-module -S`
>
asan-module is another ModulePass, not a commandline option.  You can't mix
that like this.

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
> On Tue, Sep 25, 2018 at 4:09 AM Philip Pfaffe <philip.pfaffe at
gmail.com>
> wrote:
> >
> > Frontends _are_ using PassBuilder, but they need to hook into the
> default pipeline creation to insert the sanitizer passes.
> >
> > On Tue, Sep 25, 2018 at 12:15 PM Fedor Sergeev <fedor.sergeev at
azul.com>
> wrote:
> >>
> >> Hmm... frontends should be using PassBuilder anyway.
> >> And if they are using PassBuilder then they are using
PassRegistry.def
> as well - all the
> >> PassBuilder::register*/parse*/is* methods do include
PassRegistry.def
> in their bodies.
> >>
> >> I was under impression that callbacks are primarily for plugins
usage.
> >>
> >> regards,
> >>   Fedor.
> >>
> >> On 09/25/2018 12:43 PM, Philip Pfaffe wrote:
> >>
> >> Hi Leonard, Fedor,
> >>
> >> while it's true that RegisterPass is not applicable for new-pm
passes,
> PassRegistry.def is not the whole story. Passes in PassRegistry are
> available for the opt tool. The sanitizers are passes that usually get
> added to the pipeline by the frontend. There, you need to use
PassBuilder's
> callbacks mechanism to hook the sanitizer into the optimizer.
> >>
> >> Assuming you're willing to contribute your changes, please
share your
> progress! Thank you for making a move on this!
> >>
> >> Cheers,
> >> Philip
> >>
> >> On Tue, Sep 25, 2018 at 8:27 AM Fedor Sergeev via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >>>
> >>> Leonard,
> >>>
> >>> nope, the PassRegistry stuff is all about legacy pass manager.
> >>> legacy namespace has not been extensively used to mark all the
> >>> legacy-related stuff
> >>> (say, even Pass class which is a base for legacy passes is not
under
> >>> legacy namespace).
> >>>
> >>> Registration for new-pass-manager passes happens in
> >>> lib/Passes/PassRegistry.def.
> >>>
> >>> Usually, when porting from legacy to new the main difference
is
> analysis
> >>> handling,
> >>> so people factor out the worker code into a method that takes
analyses
> >>> and call
> >>> this function both in legacy and new-pm passes.
> >>> In many cases it takes just a handful lines of code.
> >>>
> >>> Feel free to ask questions, if any.
> >>>
> >>> regards,
> >>>    Fedor.
> >>>
> >>> On 09/25/2018 02:54 AM, Leonard Chan via llvm-dev wrote:
> >>>  > Hi all,
> >>>  >
> >>>  > I'm attempting to move the AddressSanitizer pass
from the legacy
> >>>  > PassManager to the new one because the new one has
various benefits
> >>>  > over legacy and wanted to clarify on something. Does
creating the
> >>>  > static RegisterPass struct register the pass with the
new
> PassManager?
> >>>  >
> >>>  > It seems that RegisterPass does the same things that the
> >>>  > INITIALIZE_PASS_* macros do but it registers the pass
with
> >>>  > PassRegistry::getPassRegistry(). What I'm not sure
of is if this
> uses
> >>>  > the new PassManager infrastructure. Exploring the code
doesn't seem
> to
> >>>  > show that this PassRegistry touches anything in the
legacy
> namespace,
> >>>  > but I wanted double confirmation on this.
> >>>  >
> >>>  > Thanks,
> >>>  > Leonard
> >>>  > _______________________________________________
> >>>  > LLVM Developers mailing list
> >>>  > llvm-dev at lists.llvm.org
> >>>  > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>>
> >>> _______________________________________________
> >>> LLVM Developers mailing list
> >>> llvm-dev at lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180927/8c7650b0/attachment.html>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180927/c3e89a70/attachment.html>

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