search for: fepgo

...;> Hi Fred, >>> >>> My understanding is that you were specifically investigating whether >>> Apple needed compatibility for merging indexed profiles. Is that >>> compatibility needed? The only compelling argument I have heard to continue >>> to expose FEPGO is that Apple may have a compatibility requirement for >>> merging indexed profiles from previous compiler versions. >>> >>> >>> Sorry no, my comment had nothing to do with merging profiles. I >>> understand that this will break, and it might very well b...

...>>>> My understanding is that you were specifically investigating whether >>>>> Apple needed compatibility for merging indexed profiles. Is that >>>>> compatibility needed? The only compelling argument I have heard to continue >>>>> to expose FEPGO is that Apple may have a compatibility requirement for >>>>> merging indexed profiles from previous compiler versions. >>>>> >>>>> >>>>> Sorry no, my comment had nothing to do with merging profiles. I >>>>> understand that t...

...t;> Sorry it took me so long. >> >> Hi Fred, >> >> My understanding is that you were specifically investigating whether Apple needed compatibility for merging indexed profiles. Is that compatibility needed? The only compelling argument I have heard to continue to expose FEPGO is that Apple may have a compatibility requirement for merging indexed profiles from previous compiler versions. > > Sorry no, my comment had nothing to do with merging profiles. I understand that this will break, and it might very well be an issue for us, but I think there is a more fundame...

...this soon. > > Sorry it took me so long. > > Hi Fred, > > My understanding is that you were specifically investigating whether Apple needed compatibility for merging indexed profiles. Is that compatibility needed? The only compelling argument I have heard to continue to expose FEPGO is that Apple may have a compatibility requirement for merging indexed profiles from previous compiler versions. Sorry no, my comment had nothing to do with merging profiles. I understand that this will break, and it might very well be an issue for us, but I think there is a more fundamental issue...

...gt;>> >>>> My understanding is that you were specifically investigating whether >>>> Apple needed compatibility for merging indexed profiles. Is that >>>> compatibility needed? The only compelling argument I have heard to continue >>>> to expose FEPGO is that Apple may have a compatibility requirement for >>>> merging indexed profiles from previous compiler versions. >>>> >>>> >>>> Sorry no, my comment had nothing to do with merging profiles. I >>>> understand that this will break, and...

...avior, and then change the default for the following release. Someone relying on the current behavior would then be able to change their builds to use the =stable option so that they won’t be broken when the default switches. > > -fprofile-instr-generate=stable would basically correspond to FEPGO / FE coverage instrumentation. -fprofile-instr-generate=unstable would basically correspond to IRPGO. > > What do you think? > > -- Sean Silva > > > I also think a new option is cleaner (again I don’t care about the name), but if people feel that -fprofile-instr-generate=[...

...enerate becomes context-sensitive. But, (1) it doesn't break existing common workflows and (2) it makes it easier to ship IRPGO. The big caveat here is that we'll need to wait a bit and see if our internal users are OK with this. > > Is there a reason to even have the possibility for FEPGO in the long run? From what I can tell, at most we would add a -fuse-the-old-pgo-because-i-want-to-merge-with-old-profiles option to hold people over until they can regenerate their profiles with the current compiler. We can add a flag to control what pre-instrumentation is done to retain the source...

...comes > context-sensitive. But, (1) it doesn't break existing common workflows and > (2) it makes it easier to ship IRPGO. The big caveat here is that we'll > need to wait a bit and see if our internal users are OK with this. > Is there a reason to even have the possibility for FEPGO in the long run? >From what I can tell, at most we would add a -fuse-the-old-pgo-because-i- want-to-merge-with-old-profiles option to hold people over until they can regenerate their profiles with the current compiler. We can add a flag to control what pre-instrumentation is done to retain the s...

...nsitive. But, (1) it doesn't break existing common workflows and >> (2) it makes it easier to ship IRPGO. The big caveat here is that we'll >> need to wait a bit and see if our internal users are OK with this. >> > > Is there a reason to even have the possibility for FEPGO in the long run? > From what I can tell, at most we would add a -fuse-the-old-pgo-because-i- > want-to-merge-with-old-profiles option to hold people over until they can > regenerate their profiles with the current compiler. We can add a flag to > control what pre-instrumentation is done...

...ng David Li via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> Sounds fine to me, though I am not a fan of using unstable in the option. >> I think a more meaningful way (that capture the essence of the difference) >> is the following naming: >> 1) FEPGO: -fprofile-instr-generate=source or >> -fprofile-instr-generate=region >> 2) IR: -fprofile-instr-generate=cfg or -fprofile-instr-generate=graph >> >> Also since -fprofile-instr-generate= form is already used to specify raw >> profile path, we may need a different driv...

...cial for non-game workloads (which is most code). > > > > Yes, Rong is re-collecting performance data before submitting the patch. > > - Warnings > > We identified 3 classes of issues which manifest as spammy warnings when applying profile data with IRPGO (these affect FEPGO also I believe, but we looked in depth at IRPGO): > > 1. The main concerning one is that getPGOFuncName mangles the filename into the counter name. This causes us to get instrprof_error::unknown_function when the pgo-use build is done in a different build directory from the training build (w...

...or our use cases, inlining does all the work, but we're not opposed to having more passes, which might be beneficial for non-game workloads (which is most code). - Warnings We identified 3 classes of issues which manifest as spammy warnings when applying profile data with IRPGO (these affect FEPGO also I believe, but we looked in depth at IRPGO): 1. The main concerning one is that getPGOFuncName mangles the filename into the counter name. This causes us to get instrprof_error::unknown_function when the pgo-use build is done in a different build directory from the training build (which is a...

...ists.llvm.org> wrote: >>> >>>> >>>> Sounds fine to me, though I am not a fan of using unstable in the >>>> option. I think a more meaningful way (that capture the essence of the >>>> difference) is the following naming: >>>> 1) FEPGO: -fprofile-instr-generate=source or >>>> -fprofile-instr-generate=region >>>> 2) IR: -fprofile-instr-generate=cfg or -fprofile-instr-generate=graph >>>> >>>> Also since -fprofile-instr-generate= form is already used to specify >>>> raw pr...

...; >> llvm-dev at lists.llvm.org> wrote: >> >>> >>> Sounds fine to me, though I am not a fan of using unstable in the >>> option. I think a more meaningful way (that capture the essence of the >>> difference) is the following naming: >>> 1) FEPGO: -fprofile-instr-generate=source or >>> -fprofile-instr-generate=region >>> 2) IR: -fprofile-instr-generate=cfg or -fprofile-instr-generate=graph >>> >>> Also since -fprofile-instr-generate= form is already used to specify raw >>> profile path, we may n...

...neficial for non-game > workloads (which is most code). > > > Yes, Rong is re-collecting performance data before submitting the patch. > - Warnings > > We identified 3 classes of issues which manifest as spammy warnings when > applying profile data with IRPGO (these affect FEPGO also I believe, but we > looked in depth at IRPGO): > > 1. The main concerning one is that getPGOFuncName mangles the filename > into the counter name. This causes us to get > instrprof_error::unknown_function when the pgo-use build is done in a > different build directory from th...

...>>>> >>>>> >>>>> Sounds fine to me, though I am not a fan of using unstable in the >>>>> option. I think a more meaningful way (that capture the essence of the >>>>> difference) is the following naming: >>>>> 1) FEPGO: -fprofile-instr-generate=source or >>>>> -fprofile-instr-generate=region >>>>> 2) IR: -fprofile-instr-generate=cfg or -fprofile-instr-generate=graph >>>>> >>>>> Also since -fprofile-instr-generate= form is already used to specify >&gt...

...gt; opposed to having more passes, which might be beneficial for non-game >> workloads (which is most code). >> >> >> - Warnings >> >> We identified 3 classes of issues which manifest as spammy warnings when >> applying profile data with IRPGO (these affect FEPGO also I believe, but we >> looked in depth at IRPGO): >> >> 1. The main concerning one is that getPGOFuncName mangles the filename >> into the counter name. This causes us to get >> instrprof_error::unknown_function when the pgo-use build is done in a >> different...

...he work, but we're not > opposed to having more passes, which might be beneficial for non-game > workloads (which is most code). > > > - Warnings > > We identified 3 classes of issues which manifest as spammy warnings when > applying profile data with IRPGO (these affect FEPGO also I believe, but we > looked in depth at IRPGO): > > 1. The main concerning one is that getPGOFuncName mangles the filename > into the counter name. This causes us to get > instrprof_error::unknown_function when the pgo-use build is done in a > different build directory from th...

...asses, which might be beneficial for non-game >>> workloads (which is most code). >>> >>> >>> - Warnings >>> >>> We identified 3 classes of issues which manifest as spammy warnings when >>> applying profile data with IRPGO (these affect FEPGO also I believe, but we >>> looked in depth at IRPGO): >>> >>> 1. The main concerning one is that getPGOFuncName mangles the filename >>> into the counter name. This causes us to get >>> instrprof_error::unknown_function when the pgo-use build is done in...

...il/llvm-dev/2016-May/100061.html). * Sean Silva has kicked off a discussion on [the state of IRPGO](http://lists.llvm.org/pipermail/llvm-dev/2016-May/100021.html). You might ask what is IRPGO? This is profile-guided optimisation performed through instrumentation at the LLVM IR level, as opposed to FEPGO where instrumentation is added by the frontend (e.g. Clang), prior to lowering to IR. Sean would like to make IRPGO the default on all platforms other than Apple at the moment (who may require a longer deprecation period). A number of followup comments discuss possibilities for ensuring all platfor...