[llvm-dev] Advice for Porting SafeStack to New Pass Manager (original) (raw)
Leonard Chan via llvm-dev llvm-dev at lists.llvm.org
Wed Jan 2 11:44:12 PST 2019
- Previous message: [llvm-dev] [HWASAN] Is Buildbot missing hwasan tests?
- Next message: [llvm-dev] [RFC][llvm-mca] Adding binary support to llvm-mca.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> My question is what would be the correct way to proceed with porting > TargetPassConfig to the new PM? Normally, what I have done before and > what I have seen from other examples is to separate the logic of what > the pass does to an IRUnit and the pass itself into 2 separate > classes, then an instance of the class that contains the logic can be > owned by a pass for the new PM. The only trouble I see with this is > that this will require a lot of refactoring (that I started but > haven't finished), since TargetPassConfig is the parent to many other > passes/analyses and these classes override many virtual methods in > TargetPassConfig, so it may not be the cleanest solution and > potentially prone to a lot of error. When possible separation of IR analysis/transformation logic from the pass-manager-specific pass/analysis housekeeping provides a cleanest way to share code between legacy and newpm while avoiding any ill dependencies. In some cases this was done by NewPM pass instance reusing the LegacyPass class as an instance that does the actual transformation.
Yet, as I scan through TargetPassConfig, it looks more like a PassBuilder/PassManager rather than an analysis.
Do you know of other analyses that also act like pass builders/managers that were ported to new PM?
Thanks, Leonard
- Previous message: [llvm-dev] [HWASAN] Is Buildbot missing hwasan tests?
- Next message: [llvm-dev] [RFC][llvm-mca] Adding binary support to llvm-mca.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]