[llvm-dev] [GSoC 2016] Capture Tracking Improvements - Mid term report

[Sanjoy Das via llvm-dev]

Hi Scott,

On Fri, Jun 17, 2016 at 11:54 AM, Scott Egerton via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Over the past two weeks I have been learning a lot more about capture
> tracking. From this I was able to instrument the current implementation in
> order to identify some of the false positives in it. I was hoping to have

How are you instrumenting the analysis to identify false positives?

> more definitive results by now than what I currently have, but due to some
> unforeseen issues with the output becoming scrambled I cannot provide this
> just yet. I have now resolved this and plan to have some more concrete
> results within the coming week.
>
> The current algorithm for Capture tracking will look through the uses of a
> pointer. If there are too many uses it will conservatively say that the
> value is captured to avoid taking up too much compile time. If not it will
> then determine whether or not the Value is captured in various ways based on
> its opcode.
> However there are some deficiencies with the current implementation. Such as
> the false positives and the fact that it takes rather a lot of compile time
> to run.
>
> I am currently compiling a large piece of code with an instrumented version

Can you give some more details here?  What is this large piece of
code?

> of LLVM in order to identify false positives. I then plan to fix all the
> identified false positives. After this is complete I will be be moving onto

This sounds reasonable, but I'd say it is better to avoid this kind of
workflow:

  for (every_false_positive)
    understand_false_positive;
  for (every_false_positive)
    fix_false_positive;

but have it be more like:

  for (every_false_positive) {
    understand_false_positive;
    fix_false_positive;
  }

i.e. you don't have to understand _all_ of the cases where our capture
tracking is too conservative to make it better.  Find one _specific_
case where LLVM today is stupid today, and fix it; and iterate.
Making these kind of small changes will also increase the trust the
community has in you, which will be helpful when you start proposing
bigger changes (e.g. perhaps for non-escaping subgraphs).

-- Sanjoy