<div dir="ltr"><div dir="ltr">On Thu, Jul 8, 2021 at 6:59 PM Teresa Johnson <<a href="mailto:tejohnson@google.com">tejohnson@google.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>I was actually just typing up a reply welcoming contributions and to suggest you give the existing profile support a try - I realized I need to add documentation for the usage to llvm/clang's docs which I will do soon but it sounds like you figured it out ok.</div></div></div></blockquote><div><br></div><div>Yeah, I can still read code -- believe it or not! :-)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>It would be difficult to add all of this information for every allocation and particularly every access without being prohibitively expensive. Right now we have the ave/min/max lifetime, and just a single boolean per context indicating whether there was a lifetime overlap with the prior allocation for that context. We can probably expand this a bit to have somewhat richer aggregate information, but like I said, recording and emitting all start/end times and timestamps will be an overwhelming amount of information. As I mentioned in my other response, initially the goal is to provide hints about hotness and lifetime length (short vs long) to the memory allocator so that it can make smarter decisions about how and where to allocate data.<br></div></div></div></blockquote><div><br></div><div>Yes, I understand that the task is very challenging and there are a lot of limitations / compromises to make all around.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote">Definitely interested in contributions or ideas on how we could collect richer information with the approach we're taking (allocations tracked by the runtime per context and fast shadow memory based updates for accesses).<br></div></div></blockquote><div><br></div><div>I guess the best way to approach this is by trying real workloads and investigating what works and what doesn't. Would be happy to contribute to this -- please keep me in the loop and drop a line when you'll have something ready to play with.</div><div><br></div><div>Our team is busy at the moment with BOLT improvements (ARM64, shared libs, Golang support, etc); after that, hopefully we'll be able to join data profile development efforts.</div><div><br></div><div>Yours,<br>Andrey</div><div><br></div></div></div>