llvm dev - Sep 2018 - Porting Pass to New PassManager

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/20180925/61c6f4cd/attachment.html>

So I think I have the AddressSanitizer working with the new PM seeing
that I can replace '-asan' with ' -passes='asan' ' and
the IR gets
instrumented. The next thing I'm having trouble understanding is that
the AddressSanitizerModule pass doesn't seem to be running even with
'-asan-module'. That is, running

`opt < %s -passed='asan' -asan-module -S`

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

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