similar to: The state of IRPGO (3 remaining work items)

On Wed, May 25, 2016 at 12:12 PM, Sean Silva <chisophugis at gmail.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. >> >> >> - Driver changes >> >> We'd like to make IRPGO the

On Tue, May 24, 2016 at 3:41 PM, Vedant Kumar <vsk at apple.com> wrote: > > > 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

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. > > > - Driver changes > > We'd like to make IRPGO the default on PS4. We also think that it would be

On Wed, May 25, 2016 at 2:17 PM, Xinliang David Li <davidxl at google.com> wrote: > > > On Wed, May 25, 2016 at 12:12 PM, Sean Silva <chisophugis at gmail.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

> On May 24, 2016, at 5:21 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Tue, May 24, 2016 at 3:41 PM, Vedant Kumar <vsk at apple.com <mailto:vsk at apple.com>> wrote: > > > On May 23, 2016, at 8:56 PM, Xinliang David Li <davidxl at google.com <mailto:davidxl at google.com>> wrote: > > > > On Mon, May 23, 2016 at

> 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

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. > > > - Driver changes > > We'd like to make IRPGO the default on PS4. We also think that it would be > beneficial to make IRPGO the default PGO on all platforms (coverage would >

It sounds to me we are likely to converge on the following: 1) Making IR/llvm based PGO the default; 2) Enhance -fcoverage-mapping such that it automatically turns on FE based instrumentation 3) if -fcoverage-mapping is used together with -fprofile-instr-generate, -fcoverage-mapping serves as a switch to turn on FE based instrumetnation All the above are transparent to users. The following are

> On Jun 1, 2016, at 1:46 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Tue, May 31, 2016 at 6:02 PM, Frédéric Riss <friss at apple.com <mailto:friss at apple.com>> wrote: > >> On May 24, 2016, at 5:21 PM, Sean Silva <chisophugis at gmail.com <mailto:chisophugis at gmail.com>> wrote: >> >> >> >> On

> On Jun 2, 2016, at 12:10 AM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Wed, Jun 1, 2016 at 5:46 PM, Frédéric Riss <friss at apple.com <mailto:friss at apple.com>> wrote: > >> On Jun 1, 2016, at 1:46 PM, Sean Silva <chisophugis at gmail.com <mailto:chisophugis at gmail.com>> wrote: >> >> >> >> On

On Thu, Jun 2, 2016 at 5:30 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Thu, Jun 2, 2016 at 2:51 PM, Frédéric Riss <friss at apple.com> wrote: > >> >> On Jun 2, 2016, at 12:10 AM, Sean Silva <chisophugis at gmail.com> wrote: >> >> >> >> On Wed, Jun 1, 2016 at 5:46 PM, Frédéric Riss <friss at apple.com> wrote:

> On Jun 2, 2016, at 5:30 PM, Sean Silva <chisophugis at gmail.com> wrote: > > This also means that if the consensus is that -fprofile-instr-generate should really change its meaning to mean IRPGO, I’m open to having this internal patch on our side. > > Yeah, it sounds like someone is going to have to keep a "private patch" to change the default. At that point

Quick update. I've gotten derailed from posting a patch for this due to focusing on higher priority PGO inlining work. No ETA. -- Sean Silva On Fri, Jun 3, 2016 at 6:06 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Thu, Jun 2, 2016 at 6:41 PM, Xinliang David Li <davidxl at google.com> > wrote: > >> >> >> On Thu, Jun 2, 2016 at 5:30

On Thu, Jun 2, 2016, 6:41 PM Xinliang David Li via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Jun 2, 2016 at 5:30 PM, Sean Silva <chisophugis at gmail.com> wrote: > >> >> >> On Thu, Jun 2, 2016 at 2:51 PM, Frédéric Riss <friss at apple.com> wrote: >> >>> >>> On Jun 2, 2016, at 12:10 AM, Sean Silva <chisophugis at

On Fri, Sep 4, 2015 at 9:11 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Fri, Sep 4, 2015 at 5:42 PM, Xinliang David Li <davidxl at google.com> > wrote: >> >> On Fri, Sep 4, 2015 at 5:21 PM, Sean Silva <chisophugis at gmail.com> wrote: >> > >> > >> > On Fri, Sep 4, 2015 at 3:57 PM, Xinliang David Li <davidxl at

On Fri, Sep 4, 2015 at 11:03 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Fri, Sep 4, 2015 at 10:11 PM, Xinliang David Li <davidxl at google.com> > wrote: >> >> On Fri, Sep 4, 2015 at 9:11 PM, Sean Silva <chisophugis at gmail.com> wrote: >> > >> > >> > On Fri, Sep 4, 2015 at 5:42 PM, Xinliang David Li <davidxl at

On Mon, Jun 27, 2016 at 2:53 PM Xinliang David Li <davidxl at google.com> wrote: > There is some misunderstanding about the intention of this flag. The > purpose of the flag is not to turn on profile instrumentation (which > already has -fprofile-instr-generate or -fprofile-generate for it), but to > select which instrumentors to use for PGO (IR or FE). I prefer fewer flags

>> >> >> >> yes -- it is fixed length (8byte) blob which may include null byte in >> >> the middle. >> > >> > >> > For reference, MD5 sum is 16 bytes (128-bit): >> > https://en.wikipedia.org/wiki/MD5 >> >> yes, LLVM's MD5 hash only takes the lower 64bit. >> >> >> > >> >>

There is no further response to this, so I will assume general direction of solution-3 is acceptable ;) Solution-3 can be further improved. Instead of using static symbol table (with zero size __llvm_prf_nm symbols) to store function names for profile display and coverage mapping, the function names can be stored compressed in a non-allocatable section. The compression ratio for function name

On Sun, Jun 26, 2016 at 10:21 PM, Dean Michael Berris <dberris at google.com> wrote: > > > On Mon, Jun 27, 2016 at 2:53 PM Xinliang David Li <davidxl at google.com> > wrote: > >> There is some misunderstanding about the intention of this flag. The >> purpose of the flag is not to turn on profile instrumentation (which >> already has