search for: fpgo

...; >> Also since -fprofile-instr-generate= form is already used to specify raw >> profile path, we may need a different driver option. Alternatives include >> 1) -fprofile-instrument=<...> -- this maps directly to the cc1 option we >> have today >> or >> 2) -fpgo-instr=<> -- suggested by Fred or >> 3) -fpgo-instr-method=<...> >> > > Random bikeshedding. I like fprofile-instrument because it merges a lot of > similar ideas behind instrumenting - and oddly enough what I was suggesting > in the x-ray thread before seeing thi...

...lready used to specify >>>> raw profile path, we may need a different driver option. Alternatives >>>> include >>>> 1) -fprofile-instrument=<...> -- this maps directly to the cc1 option >>>> we have today >>>> or >>>> 2) -fpgo-instr=<> -- suggested by Fred or >>>> 3) -fpgo-instr-method=<...> >>>> >>> >>> Random bikeshedding. I like fprofile-instrument because it merges a lot >>> of similar ideas behind instrumenting - and oddly enough what I was >>>...

...e -fprofile-instr-generate= form is already used to specify raw >>> profile path, we may need a different driver option. Alternatives include >>> 1) -fprofile-instrument=<...> -- this maps directly to the cc1 option we >>> have today >>> or >>> 2) -fpgo-instr=<> -- suggested by Fred or >>> 3) -fpgo-instr-method=<...> >>> >> >> Random bikeshedding. I like fprofile-instrument because it merges a lot >> of similar ideas behind instrumenting - and oddly enough what I was >> suggesting in the x-ray...

...gt;>>>> raw profile path, we may need a different driver option. Alternatives >>>>> include >>>>> 1) -fprofile-instrument=<...> -- this maps directly to the cc1 option >>>>> we have today >>>>> or >>>>> 2) -fpgo-instr=<> -- suggested by Fred or >>>>> 3) -fpgo-instr-method=<...> >>>>> >>>> >>>> Random bikeshedding. I like fprofile-instrument because it merges a lot >>>> of similar ideas behind instrumenting - and oddly enough what...

...coverage (and possibly for a deprecation >>> period if users want to merge indexed profiles). >>> >>> >>> FEPGO needs to be a possibility. And the instrumentation code needs to >>> be there anyway for the coverage. Here’s a proposal: >>> - Add -fpgo-instr=[llvm|clang] to choose which kind of PGO >>> instrumentation you want >>> - make -fpgo-instr=llvm incompatible with with -fcoverage-mapping >>> - deprecate -fprofile-instr-generate, and remove it after a couple >>> releases >>> >>> (I re...

...ing in conjunction with coverage (and possibly for a deprecation >> period if users want to merge indexed profiles). >> >> >> FEPGO needs to be a possibility. And the instrumentation code needs to be >> there anyway for the coverage. Here’s a proposal: >> - Add -fpgo-instr=[llvm|clang] to choose which kind of PGO >> instrumentation you want >> - make -fpgo-instr=llvm incompatible with with -fcoverage-mapping >> - deprecate -fprofile-instr-generate, and remove it after a couple >> releases >> >> (I really don’t care about th...

...or a deprecation >>>> period if users want to merge indexed profiles). >>>> >>>> >>>> FEPGO needs to be a possibility. And the instrumentation code needs to >>>> be there anyway for the coverage. Here’s a proposal: >>>> - Add -fpgo-instr=[llvm|clang] to choose which kind of PGO >>>> instrumentation you want >>>> - make -fpgo-instr=llvm incompatible with with -fcoverage-mapping >>>> - deprecate -fprofile-instr-generate, and remove it after a couple >>>> releases >>>&gt...

...y need to continue exposing that except as a weird thing in conjunction with coverage (and possibly for a deprecation period if users want to merge indexed profiles). FEPGO needs to be a possibility. And the instrumentation code needs to be there anyway for the coverage. Here’s a proposal: - Add -fpgo-instr=[llvm|clang] to choose which kind of PGO instrumentation you want - make -fpgo-instr=llvm incompatible with with -fcoverage-mapping - deprecate -fprofile-instr-generate, and remove it after a couple releases (I really don’t care about the names) I think it is a better way forward to hav...

...ell, 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-level robustness of FEPGO (e.g. -fpgo-no-simplify-before-instrumenting or something). > One alternative is to introduce a separate driver flag for IRPGO. This > might not work well for Sony's existing users. I'd be interested in any > feedback about this approach. > Personally, I would prefer to maintaining comma...

...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-level robustness of FEPGO (e.g. -fpgo-no-simplify-before-instrumenting or something). >>>> >>>> >>>> One alternative is to introduce a separate driver flag for IRPGO. This might not work well for Sony's existing users. I'd be interested in any feedback about this approach. >>>>...

...d 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-level > robustness of FEPGO (e.g. -fpgo-no-simplify-before-instrumenting or > something). > > >> One alternative is to introduce a separate driver flag for IRPGO. This >> might not work well for Sony's existing users. I'd be interested in any >> feedback about this approach. >> > > Personall...

...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-level robustness of FEPGO (e.g. -fpgo-no-simplify-before-instrumenting or something). > > > One alternative is to introduce a separate driver flag for IRPGO. This might not work well for Sony's existing users. I'd be interested in any feedback about this approach. > > Personally, I would prefer to maintaining...

...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-level robustness of FEPGO (e.g. -fpgo-no-simplify-before-instrumenting or something). >> >> >> One alternative is to introduce a separate driver flag for IRPGO. This might not work well for Sony's existing users. I'd be interested in any feedback about this approach. >> >> Personally, I would pr...

> On May 23, 2016, at 8:56 PM, Xinliang David Li <davidxl at google.com> wrote: > > On Mon, May 23, 2016 at 8:23 PM, Sean Silva <chisophugis at gmail.com> wrote: > Jake and I have been integrating IRPGO on PS4, and we've identified 3 remaining work items. > > Sean, thanks for the write up. It matches very well with what we think as well. + 1 > - Driver