search for: samplepgo

Dehao and I have been discussing changes we need to make to SamplePGO to make it more effective. Currently, SamplePGO is a scalar pass that limits itself to add branch weight annotations. It runs pretty early in the pipeline, so this is fine for other scalar passes that want to use profile data (block layout and regalloc). However, it does nothing to help module p...

If Hal's proposal is for SamplePGO purpose, let me clarify some design principles of SamplePGO. The profile for sample pgo uses source location as the key to map the execution count back to IR. This design is based on the principle that we do not want the profile to be tightly couple with compiler IR. Instead, profile is simple an...

...can make it more readable... On Tue, Nov 1, 2016 at 2:07 PM, Dehao Chen <dehao at google.com> wrote: > Oops... pressed the wrong button and sent out early... > > On Tue, Nov 1, 2016 at 2:01 PM, Dehao Chen <dehao at google.com> wrote: > >> If Hal's proposal is for SamplePGO purpose, let me clarify some design >> principles of SamplePGO. >> >> The profile for sample pgo uses source location as the key to map the >> execution count back to IR. This design is based on the principle that we >> do not want the profile to be tightly couple with...

...now on? The >> latter would be a problem for us. >> > > Open to negotiation, but this change is intentional ( for details, see the > commit: http://llvm.org/viewvc/llvm-project?rev=218129&view=rev ). > Well, this breaks us. Very hard. It absolutely blocks us from using SamplePGO with LLVM. The alternative would be to make the compiler use absolute line numbers, but in the experience we've collected with GCC, this makes the profiles very brittle wrt source changes. I don't have a better idea atm. Would there be any other way to generate relative line numbers? Per...

Motivation: Many optimizations duplicate code. E.g. loop unroller duplicates the loop body, GVN duplicates computation, etc. The duplicated code will share the same debug info with the original code. For SamplePGO, the debug info is used to present the profile. Code duplication will affect profile accuracy. Taking loop unrolling for example: #1 foo(); #2 for (i = 0; i < N; i++) { #3 bar(); #4 } If N is 8 during runtime, a reasonable profile will look like: #1: 10 #3: 80 But if the compiler unrolls t...

...1:39 AM, Dehao Chen <dehao at google.com> wrote: > >> Motivation: >> Many optimizations duplicate code. E.g. loop unroller duplicates the loop >> body, GVN duplicates computation, etc. The duplicated code will share the >> same debug info with the original code. For SamplePGO, the debug info is >> used to present the profile. Code duplication will affect profile accuracy. >> Taking loop unrolling for example: >> >> #1 foo(); >> #2 for (i = 0; i < N; i++) { >> #3 bar(); >> #4 } >> >> If N is 8 during runtime, a r...

...t that approach because we will end up discussing everything at once and it may not lead to concrete progress. Another approach would be to present each issue individually either as patches or RFCs or bugs. I will be taking on the implementation of several of these issues. Some of them involve the SamplePGO harness that I added last year. I would also like to know what other bugs or problems people have in mind that I could also roll into this work. Thanks. Diego. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/...

...t;> >>> >>> Open to negotiation, but this change is intentional ( for details, see >>> the commit: http://llvm.org/viewvc/llvm-project?rev=218129&view=rev ). >>> >> >> Well, this breaks us. Very hard. It absolutely blocks us from using >> SamplePGO with LLVM. >> > > Sorry about that - I knew ASan needed gmlt data of a certain form and > worked carefully to ensure llvm-symbolizer could still symbolize with these > changes, but wasn't aware of this particular dependence from PGO (just > assumed it used the line table di...

...u, Oct 27, 2016 at 11:39 AM, Dehao Chen <dehao at google.com> wrote: > Motivation: > Many optimizations duplicate code. E.g. loop unroller duplicates the loop > body, GVN duplicates computation, etc. The duplicated code will share the > same debug info with the original code. For SamplePGO, the debug info is > used to present the profile. Code duplication will affect profile accuracy. > Taking loop unrolling for example: > > #1 foo(); > #2 for (i = 0; i < N; i++) { > #3 bar(); > #4 } > > If N is 8 during runtime, a reasonable profile will look like: &g...

...hu, Oct 27, 2016 at 11:39 AM Dehao Chen <dehao at google.com> wrote: > Motivation: > Many optimizations duplicate code. E.g. loop unroller duplicates the loop > body, GVN duplicates computation, etc. The duplicated code will share the > same debug info with the original code. For SamplePGO, the debug info is > used to present the profile. Code duplication will affect profile accuracy. > Taking loop unrolling for example: > > #1 foo(); > #2 for (i = 0; i < N; i++) { > #3 bar(); > #4 } > > If N is 8 during runtime, a reasonable profile will look like: &g...

...iation, but this change is intentional ( for details, see > >>>> the commit: http://llvm.org/viewvc/llvm-project?rev=218129&view=rev > ). > >>> > >>> > >>> Well, this breaks us. Very hard. It absolutely blocks us from using > >>> SamplePGO with LLVM. > >> > >> > >> Sorry about that - I knew ASan needed gmlt data of a certain form and > >> worked carefully to ensure llvm-symbolizer could still symbolize with > these > >> changes, but wasn't aware of this particular dependence from PG...

...e.com > > > wrote: > > > > Oops... pressed the wrong button and sent out early... > > > > > > On Tue, Nov 1, 2016 at 2:01 PM, Dehao Chen < dehao at google.com > > > > wrote: > > > > > > > If Hal's proposal is for SamplePGO purpose, let me clarify some > > > > design principles of SamplePGO. > > > > > > > > > > The profile for sample pgo uses source location as the key to > > > > map > > > > the > > > > execution count back to IR. This d...

...DebugLoc > attached to instructions. Things get a little hairy at -O3 (or with > -flto) because there are optimizations bugs so transformations don't > preserve debuginfo. This is not entirely orthogonal but something can > be worked on in parallel (bonus point, this would also help SamplePGO > & debuginfo experience). With `-flto` the problem gets amplified more, > as expected. > > 5) I found a couple of issue when trying the support, but I'm actively > working on them. > https://bugs.llvm.org/show_bug.cgi?id=33773 <https://bugs.llvm.org/show_bug.cgi?id=33...

...<dehao at google.com> wrote: >> >>> Motivation: >>> Many optimizations duplicate code. E.g. loop unroller duplicates the >>> loop body, GVN duplicates computation, etc. The duplicated code will share >>> the same debug info with the original code. For SamplePGO, the debug info >>> is used to present the profile. Code duplication will affect profile >>> accuracy. Taking loop unrolling for example: >>> >>> #1 foo(); >>> #2 for (i = 0; i < N; i++) { >>> #3 bar(); >>> #4 } >>> >&g...

...n to negotiation, but this change is intentional ( for details, see >>>>> the commit: http://llvm.org/viewvc/llvm-project?rev=218129&view=rev ). >>>> >>>> >>>> Well, this breaks us. Very hard. It absolutely blocks us from using >>>> SamplePGO with LLVM. >>> >>> >>> Sorry about that - I knew ASan needed gmlt data of a certain form and >>> worked carefully to ensure llvm-symbolizer could still symbolize with these >>> changes, but wasn't aware of this particular dependence from PGO (just &g...

...roach because we will end up discussing everything at once and it may not lead to concrete progress. Another approach would be to present each issue individually either as patches or RFCs or bugs. > > I will be taking on the implementation of several of these issues. Some of them involve the SamplePGO harness that I added last year. I would also like to know what other bugs or problems people have in mind that I could also roll into this work. > > > Thanks. Diego. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu...

...; > > > > > > > > > > On Tue, Nov 1, 2016 at 2:01 PM, Dehao Chen < dehao at google.com > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > If Hal's proposal is for SamplePGO purpose, let me clarify > > > > > > some > > > > > > design principles of SamplePGO. > > > > > > > > > > > > > > > > > > > > > The profile for sample pgo uses source location as the key > &gt...

Hi David, Thanks for your reply. I find that I need to add some new types of profile data that are specific to JIT environment like Function Ordering. Function Ordering is similar to dynamic call graph which records the execution of functions at runtime along with the order in which they are called. Eg: Suppose they are 5 functions (F1..F5). F1 calls other functions in the order described

Hello all, In https://www.youtube.com/watch?v=qq0q1hfzidg, Adam Nemet (cc'ed) describes optimization remarks and some future plans for the project. I had a few follow-up questions: 1. As an example of future work to be done, the talk mentions expanding the set of optimization passes that emit remarks. However, the Clang User Manual mentions that "optimization remarks do not really make

...; attached to instructions. Things get a little hairy at -O3 (or with >> -flto) because there are optimizations bugs so transformations don't >> preserve debuginfo. This is not entirely orthogonal but something can >> be worked on in parallel (bonus point, this would also help SamplePGO >> & debuginfo experience). With `-flto` the problem gets amplified more, >> as expected. >> >> 5) I found a couple of issue when trying the support, but I'm actively >> working on them. >> https://bugs.llvm.org/show_bug.cgi?id=33773 >> https://bug...