search for: devirtsccrepeatedpass

...hecks for devirtualizations after each pass and, if any occur, it re-runs the CGSCC pass pipeline. In other words: coro-split is run, a check is made for devirtualization, then coro-elide is run, and another check is made. The new pass manager allows for a series of CGSCC passes to be wrapped in a DevirtSCCRepeatedPass, but this only checks for devirtualizations after all passes are run. In the case of coro-split and coro-elide, the indirect function call is added and then devirtualized within a single pass of the repeater, so DevirtSCCRepeatedPass never sees the devirtualization and thus doesn't perform a re...

Yes, this looks broken in the new PM. The DevirtSCCRepeatedPass::run method first scans the functions in the SCC to collect value handles for indirect calls, runs the CGSCC pass pipeline and then checks if any of the call value handles now point to a direct call, in which case it runs the pipeline again (which should inline the devirtualized call) . The proble...

...nontrivial to uniquely track pass executions with counters in new pass      manager as its pipeline schedule can be dynamic. Ideas are welcome on how to efficiently      implement unique execution tracking that does not break in presence of fixed-point iteration      passes like RepeatedPass/DevirtSCCRepeatedPass      Also, the intent is for execution counters to be able provide thread-safety in multi-threaded      pipeline execution (though no work planned for it yet).   5. introduce a new analysis llvm::PassInstrumentationAnalysis      This is a convenience wrapper to provide an access to PassIns...

...hat nontrivial to uniquely track pass executions with counters in new pass manager as its pipeline schedule can be dynamic. Ideas are welcome on how to efficiently implement unique execution tracking that does not break in presence of fixed-point iteration passes like RepeatedPass/DevirtSCCRepeatedPass Also, the intent is for execution counters to be able provide thread-safety in multi-threaded pipeline execution (though no work planned for it yet). 5. introduce a new analysis llvm::PassInstrumentationAnalysis This is a convenience wrapper to provide an access to PassInstr...

...counters in new pass >       manager as its pipeline schedule can be dynamic. Ideas are > welcome > on how to efficiently >       implement unique execution tracking that does not break in > presence of fixed-point iteration >       passes like RepeatedPass/DevirtSCCRepeatedPass > >       Also, the intent is for execution counters to be able provide > thread-safety in multi-threaded >       pipeline execution (though no work planned for it yet). > >    5. introduce a new analysis llvm::PassInstrumentationAnalysis > >       This i...

...ger as its pipeline schedule can be dynamic. Ideas are >>>> welcome >>>> on how to efficiently >>>> implement unique execution tracking that does not break in >>>> presence of fixed-point iteration >>>> passes like RepeatedPass/DevirtSCCRepeatedPass >>>> >>>> Also, the intent is for execution counters to be able provide >>>> thread-safety in multi-threaded >>>> pipeline execution (though no work planned for it yet). >>>> >>>> 5. introduce a new analysis llvm...

Chandler et al, I have been playing with the new PM pipeline, being particularly interested in how it can handle devirtualization. Now, I discovered what I believe is a "regression" vs old PM on a rather simple one-translation-unit testcase. clang is able to devirtualize it with -O3 and fails to do so with -fexperimental-new-pass-manager added. It looks like a pipeline issue,

...Ideas are welcome > on how to efficiently > implement unique execution tracking that does not > break in > presence of fixed-point iteration > passes like RepeatedPass/DevirtSCCRepeatedPass > > Also, the intent is for execution counters to be > able provide > thread-safety in multi-threaded > pipeline execution (though no work planned for it > yet...

On 8/7/19 6:20 PM, Hiroshi Yamauchi wrote: > I basically run "clang > -fexperimental-new-pass-manager -print-after-all ..." > > It's conceivable that something is different in our setup or in clang > (from opt)... I'll see if I can reproduce it outside our setup. Does it depend on machine architecture? I generally use x86... regards,   Fedor. > > Thanks.