similar to: Using the new pass manager for CodeGen

Hello, I'm in the process of creating a pass for the new PM for SafeStack which is only available as a part of the legacy PM. The only thing bugging me is in regards to the TargetPassConfig analysis. Whereas most other passes/analyses I have seen separate the logic between the actual pass and anything it does to the IRUnits it runs over are in 2 separate classes, TargetPassConfig has them

Here's a sketch of the proposed approach for just one pass (but imagine more) https://reviews.llvm.org/D58845 On Fri, Mar 1, 2019 at 12:54 PM Fedor Sergeev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 2/28/19 12:47 AM, Hiroshi Yamauchi via llvm-dev wrote: > > Hi all, > > To implement more profile-guided optimizations, we’d like to use > ProfileSummaryInfo

On Sat, Mar 2, 2019 at 12:58 AM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > > > On 3/2/19 2:38 AM, Hiroshi Yamauchi wrote: > > Here's a sketch of the proposed approach for just one pass (but imagine > more) > > https://reviews.llvm.org/D58845 > > On Fri, Mar 1, 2019 at 12:54 PM Fedor Sergeev via llvm-dev < > llvm-dev at lists.llvm.org>

On 3/4/19 10:49 PM, Hiroshi Yamauchi wrote: > > > On Mon, Mar 4, 2019 at 10:55 AM Hiroshi Yamauchi <yamauchi at google.com > <mailto:yamauchi at google.com>> wrote: > > > > On Sat, Mar 2, 2019 at 12:58 AM Fedor Sergeev > <fedor.sergeev at azul.com <mailto:fedor.sergeev at azul.com>> wrote: > > > > On 3/2/19 2:38 AM,

Overall seems fine to me. On 3/11/19 8:12 PM, Hiroshi Yamauchi wrote: > Here's a revised approach based on the discussion: > > - Cache PSI right after the profile summary in the IR is written in > the pass pipeline. This would avoid the need to insert > RequireAnalysisPass for PSI before each non-module pass that needs it. > PSI can be technically invalidated but unlikely

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.

Hi all, To implement more profile-guided optimizations, we’d like to use ProfileSummaryInfo (PSI) and BlockFrequencyInfo (BFI) from more passes of various types, under the new pass manager. The following is what we came up with. Would appreciate feedback. Thanks. Issue It’s not obvious (to me) how to best do this, given that we cannot request an outer-scope analysis result from an inner-scope

On 3/14/19 2:04 AM, Hiroshi Yamauchi wrote: > > > On Wed, Mar 13, 2019 at 2:37 PM Fedor Sergeev <fedor.sergeev at azul.com > <mailto:fedor.sergeev at azul.com>> wrote: > >> >> - Add a new proxy ModuleAnalysisManagerLoopProxy for a loop pass >> to be able to get to the ModuleAnalysisManager in one step and >> PSI through it. >

On 06/07/2018 06:11 PM, Chandler Carruth wrote: > We had already talked about this, so unsurprisingly I'm generally in > favor of the direction. Some comments below. > > On Thu, Jun 7, 2018 at 2:00 AM Fedor Sergeev <fedor.sergeev at azul.com > <mailto:fedor.sergeev at azul.com>> wrote: > >    - access through LLVM Context (allows to control life-time and

Hello, (fairly new around here, apologies if the question has an obvious answer) I've been studying the structure of the new PassManager in the hopes of using it soon. After watching a couple of talks (Chandler / Sergeev), I decided to start with the Concept/Model classes in PassManagerInternal.h While I could make sense of almost everything there, two details caught my attention: 1- The

Hi Andrew, We absolutely need to be able to generate executable programs using > opt-bisect, so some mechanism for not skipping required passes is needed. > It might be nice to have a mode where no passes are skipped and the IR/MIR > is dumped when the bisect limit is reached, but I don't see that as a > requirement. > At this point it makes no sense to worry about the code

Hi Chandler, This is a high-level review of the new WIP `PassManager` infrastructure. For those that haven't dug into Chandler's commits, here's a very high-level overview (assuming IIUC): - The driver supports simple declarative syntax for specifying passes to run. E.g., `module(a,b,function(c,d),e)` runs module passes `a` and `b`, then function passes `c` and `d` for

Thanks Craig, that's exactly what I mean, stopping at particular changes inside a pass. Would you please refer me the discuss about combining opt-bisect with debug counters? Is it already under implementation? On Fri, Jun 8, 2018 at 12:19 AM Craig Topper <craig.topper at gmail.com> wrote: > I think that "level" was referring to what level of granularity the >

I was going to write something up about fine-grained opt-bisect but didn't get to it last week. We've had a -pass-max option here for some time and have hand-added instrumentation to various passes to honor it. It's saved us man-years of debug time. I was planning on sending it upstream but saw this effort with pass execution instrumentation and thought it might fit there.

On 5/14/20 5:33 AM, Arthur Eubanks via llvm-dev wrote: > > Is it the case that with the legacy PM there is no inlining at > either -O2 or -O3 and with newPM there is? Or is there something else > going on? > Legacy PM inlines at -O2/-O3, new PM inlines at -O1/-O2/-O3. These > cases where inlining occurs also coincide with the test failure. I > agree that inlining itself

On 8/6/19 7:31 PM, Fedor Sergeev via llvm-dev wrote: > > > On 8/6/19 3:02 AM, Hiroshi Yamauchi via llvm-dev wrote: >> I had a chance to try -print-after-all with NPM. >> >> It seems like there's still no output for the passes >> before objc-arc-contract (which is basically what I saw before.) Does >> anyone else see this? >> >> Are we

David, we definitely need to address this issue and I did not forget about it. I'm still fleshing out a proposal on a generic solution for "pass execution control points", which was inspired by the new pass manager needs but then it appears we can largerly reuse the implementation for both managers. Since the implementation should be based on a special Analysis, it definitely

On Tue, Apr 3, 2018 at 8:50 AM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > > Pass Manager (PassManager.h) itself, does not - it's only templates, > none of it depends on Region, Loop, etc. > Well, true but the problem happens when you try to instantiate the thing. > And for generic features like opt-bisection, ir-print-after-all etc that > want: > - to

Fedor, Yes that is what happens in my case that the loop is fully unrolled and hence ‘removed’. My objection though is that there is still IR that could be dumped (i.e. the function containing the loop that was removed or the entire module) and that is what I want to have dumped after each pass when I specify -print-after-all. Of course there may be certain implementation details that could make

Sanitizer passes really should not run before the inliner. For example, ASan moves all allocas into a "mega-alloca" to obtain fixed frame layout for reporting purposes. It also inserts a fake stack check in the function prologue which will get duplicated (but will probably still work) after inlining. MSan removes readnone/readonly from all functions because they all update shadow which