[llvm-dev] Porting Pass to New PassManager

[Fedor Sergeev via llvm-dev]

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