[llvm-dev] Porting Pass to New PassManager (original) (raw)

Leonard Chan via llvm-dev llvm-dev at lists.llvm.org
Fri Sep 28 12:11:11 PDT 2018

• Previous message: [llvm-dev] Porting Pass to New PassManager
• Next message: [llvm-dev] Porting Pass to New PassManager
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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

• Previous message: [llvm-dev] Porting Pass to New PassManager
• Next message: [llvm-dev] Porting Pass to New PassManager
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the llvm-dev mailing list