Fedor Sergeev via llvm-dev
2018-Sep-26 17:59 UTC
[llvm-dev] OptBisect implementation for new pass manager
Philip, It kinda depends on user expectations. What do you really expect as a result of your compilation when you set -opt-bisect-limit=X? Do you just get a resulting IR and scan for the bad pattern? Then you dont care about pass sequences and do brute-force bisect. Do you expect to get a runnable code at the end and check for buggy run-time behavior? Then you need to keep the passes that are required to produce runnable code. In our Java JIT compiler we have quite a number of passes where we lower the semantics to C level and those lowerings are absolutely required for the code to be runnable. regards, Fedor. On 09/26/2018 08:47 PM, Philip Pfaffe wrote:> Hi Fedor, > > can you make an example where a pass actually needs to opt-out? > Because IMO, bisect should quite literally to DebugCounter-style skip > every step in every ::run method's loop. Passes should not even be > concerned with this. > > Cheers, > Philip > > On Wed, Sep 26, 2018 at 6:54 PM Fedor Sergeev via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Greetings! > > As the generic Pass Instrumentation framework for new pass manager is > finally *in*, > I'm glad to start the discussion on implementation of -opt-bisect > through that framework. > > As it has already been discovered while porting other features > (namely, > -time-passes) > blindly copying the currently existing legacy implementation is most > likely not a perfect > way forward. Now is a chance to take a fresh look at the overall > approach and perhaps > do better, without the restrictions that legacy pass manager > framework > imposed on > the implementation. > > Kind of a summary of what we have now: > - There is a single OptBisect object, requested through LLVMContext > (managed as ManagedStatic). > > - OptBisect is defined in lib/IR, but does use analyses, > which is a known layering issue > > - Pass hierarchy provides skipModule etc helper functions > > - Individual passes opt-in to OptBisect activities by manually > calling skip* helper functions > whenever appropriate > > With current state of new-pm PassInstrumentation potential OptBisect > implementation > will have the following properties/issues: > - OptBisect object that exists per compilation pipeline, managed > similar to PassBuilder/PassManagers > (which makes it more suitable for use in parallel compilations) > > - no more layering issues imposed by implementation since > instrumentations by design > can live anywhere - lib/Analysis, lib/Passes etc > > - since Codegen is still legacy-only we will have to make a joint > implementation that > provides a sequential passes numbering through both new-PM IR > and > legacy Codegen pipelines > > - as of right now there is no mechanism for opt-in/opt-out, so it > needs to be designed/implemented > Here I would like to ask: > - what would be preferable - opt-in or opt-out? > > - with legacy implementation passes opt-in both for > bisect and > attribute-optnone support at once. > Do we need to follow that in new-pm implementation? > > Also, I would like to ask whether people see current user > interface for > opt-bisect limiting? > Do we need better controls for more sophisticated bisection? > Basically I'm looking for any ideas on improving opt-bisect user > experience that might > affect design approaches we take on the initial implementation. > > regards, > Fedor. > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180926/296c49f0/attachment.html>
Philip Pfaffe via llvm-dev
2018-Sep-26 18:41 UTC
[llvm-dev] OptBisect implementation for new pass manager
> It kinda depends on user expectations. > What do you really expect as a result of your compilation when you set > -opt-bisect-limit=X? > Do you just get a resulting IR and scan for the bad pattern? > Then you dont care about pass sequences and do brute-force bisect. >This is what I'd expect.> Do you expect to get a runnable code at the end and check for buggy > run-time behavior? > Then you need to keep the passes that are required to produce runnable > code. > In our Java JIT compiler we have quite a number of passes where we lower > the semantics > to C level and those lowerings are absolutely required for the code to be > runnable. > > regards, > Fedor. > > On 09/26/2018 08:47 PM, Philip Pfaffe wrote: > > Hi Fedor, > > can you make an example where a pass actually needs to opt-out? Because > IMO, bisect should quite literally to DebugCounter-style skip every step in > every ::run method's loop. Passes should not even be concerned with this. > > Cheers, > Philip > > On Wed, Sep 26, 2018 at 6:54 PM Fedor Sergeev via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Greetings! >> >> As the generic Pass Instrumentation framework for new pass manager is >> finally *in*, >> I'm glad to start the discussion on implementation of -opt-bisect >> through that framework. >> >> As it has already been discovered while porting other features (namely, >> -time-passes) >> blindly copying the currently existing legacy implementation is most >> likely not a perfect >> way forward. Now is a chance to take a fresh look at the overall >> approach and perhaps >> do better, without the restrictions that legacy pass manager framework >> imposed on >> the implementation. >> >> Kind of a summary of what we have now: >> - There is a single OptBisect object, requested through LLVMContext >> (managed as ManagedStatic). >> >> - OptBisect is defined in lib/IR, but does use analyses, >> which is a known layering issue >> >> - Pass hierarchy provides skipModule etc helper functions >> >> - Individual passes opt-in to OptBisect activities by manually >> calling skip* helper functions >> whenever appropriate >> >> With current state of new-pm PassInstrumentation potential OptBisect >> implementation >> will have the following properties/issues: >> - OptBisect object that exists per compilation pipeline, managed >> similar to PassBuilder/PassManagers >> (which makes it more suitable for use in parallel compilations) >> >> - no more layering issues imposed by implementation since >> instrumentations by design >> can live anywhere - lib/Analysis, lib/Passes etc >> >> - since Codegen is still legacy-only we will have to make a joint >> implementation that >> provides a sequential passes numbering through both new-PM IR and >> legacy Codegen pipelines >> >> - as of right now there is no mechanism for opt-in/opt-out, so it >> needs to be designed/implemented >> Here I would like to ask: >> - what would be preferable - opt-in or opt-out? >> >> - with legacy implementation passes opt-in both for bisect and >> attribute-optnone support at once. >> Do we need to follow that in new-pm implementation? >> >> Also, I would like to ask whether people see current user interface for >> opt-bisect limiting? >> Do we need better controls for more sophisticated bisection? >> Basically I'm looking for any ideas on improving opt-bisect user >> experience that might >> affect design approaches we take on the initial implementation. >> >> regards, >> Fedor. >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180926/d5861eb8/attachment.html>
Craig Topper via llvm-dev
2018-Sep-26 18:45 UTC
[llvm-dev] OptBisect implementation for new pass manager
opt-bisect is often used to debug why a program compiled at -O0 produces different output to a program compiled at -O1 or -O2. We want to eliminate the bad pass/optimization but still produce a working executable. ~Craig On Wed, Sep 26, 2018 at 11:41 AM Philip Pfaffe via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > It kinda depends on user expectations. >> What do you really expect as a result of your compilation when you set >> -opt-bisect-limit=X? >> Do you just get a resulting IR and scan for the bad pattern? >> Then you dont care about pass sequences and do brute-force bisect. >> > This is what I'd expect. > > >> Do you expect to get a runnable code at the end and check for buggy >> run-time behavior? >> Then you need to keep the passes that are required to produce runnable >> code. >> In our Java JIT compiler we have quite a number of passes where we lower >> the semantics >> to C level and those lowerings are absolutely required for the code to be >> runnable. >> >> regards, >> Fedor. >> >> On 09/26/2018 08:47 PM, Philip Pfaffe wrote: >> >> Hi Fedor, >> >> can you make an example where a pass actually needs to opt-out? Because >> IMO, bisect should quite literally to DebugCounter-style skip every step in >> every ::run method's loop. Passes should not even be concerned with this. >> >> Cheers, >> Philip >> >> On Wed, Sep 26, 2018 at 6:54 PM Fedor Sergeev via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Greetings! >>> >>> As the generic Pass Instrumentation framework for new pass manager is >>> finally *in*, >>> I'm glad to start the discussion on implementation of -opt-bisect >>> through that framework. >>> >>> As it has already been discovered while porting other features (namely, >>> -time-passes) >>> blindly copying the currently existing legacy implementation is most >>> likely not a perfect >>> way forward. Now is a chance to take a fresh look at the overall >>> approach and perhaps >>> do better, without the restrictions that legacy pass manager framework >>> imposed on >>> the implementation. >>> >>> Kind of a summary of what we have now: >>> - There is a single OptBisect object, requested through LLVMContext >>> (managed as ManagedStatic). >>> >>> - OptBisect is defined in lib/IR, but does use analyses, >>> which is a known layering issue >>> >>> - Pass hierarchy provides skipModule etc helper functions >>> >>> - Individual passes opt-in to OptBisect activities by manually >>> calling skip* helper functions >>> whenever appropriate >>> >>> With current state of new-pm PassInstrumentation potential OptBisect >>> implementation >>> will have the following properties/issues: >>> - OptBisect object that exists per compilation pipeline, managed >>> similar to PassBuilder/PassManagers >>> (which makes it more suitable for use in parallel compilations) >>> >>> - no more layering issues imposed by implementation since >>> instrumentations by design >>> can live anywhere - lib/Analysis, lib/Passes etc >>> >>> - since Codegen is still legacy-only we will have to make a joint >>> implementation that >>> provides a sequential passes numbering through both new-PM IR and >>> legacy Codegen pipelines >>> >>> - as of right now there is no mechanism for opt-in/opt-out, so it >>> needs to be designed/implemented >>> Here I would like to ask: >>> - what would be preferable - opt-in or opt-out? >>> >>> - with legacy implementation passes opt-in both for bisect and >>> attribute-optnone support at once. >>> Do we need to follow that in new-pm implementation? >>> >>> Also, I would like to ask whether people see current user interface for >>> opt-bisect limiting? >>> Do we need better controls for more sophisticated bisection? >>> Basically I'm looking for any ideas on improving opt-bisect user >>> experience that might >>> affect design approaches we take on the initial implementation. >>> >>> regards, >>> Fedor. >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> >> _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180926/5a6eb359/attachment.html>