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

Sanjoy Das via llvm-dev llvm-dev at lists.llvm.org
Sat Jun 18 14:16:57 PDT 2016


Hi Scott,

Scott Egerton wrote:
 > I've instrumented it so that it will output the pointer value to llvm::dbgs() whenever MayBeCaptured or
 > MayBeCapturedBefore returns true in order to identify all "positives", false or not. Then I am manually filtering out
 > all of cases which appear to be the correct behaviour. Hopefully everything left over will be a false positive.

I'm sure you know this already, but for things like capture tracking a
"false positive" to the human eye can easily be wrong. :) Have you
tried extracting out small C/C++ (or even LLVM IR) test cases that you
can point to and say "here we're clearly being too conservative"?
Once you have these, it'd be great to file a bug for each one of them:
that way even if you cannot get to some of these by the end of your
GSoC period, you or someone else can get to them later.

 >> Can you give some more details here? What is this large piece of
 >> code?
 >
 > It's the code for Firefox. I saw someone on IRC was using it as well and thought it would be good as it is supported
 > well enough to "just work".

That sounds good, assuming Firefox has good internal unit test
coverage.  I'd have gone with using clang/llvm itself, but any
code-base that has a good set of unit tests (so that you'll know if
you've been too aggressive in inferring nocapture) is okay.

 > I agree that this does seem like a better workflow, however I am finding it difficult to identify a single false
 > positive without at least finding a few because of the process I'm using, filtering the instrumented output.

That's fine, and I'm not asking you to stop trying to get a holistic
view of our weak points; *but* I'd urge you to _prioritize_ finding
and fixing a specific case, i.e. just pick any one false positive (at
random) and see why it is we're too conservative and fix the
underlying issue.  That will give you a much better idea of what's
approachable, and what isn't; and will help build trust within the
community.

Thanks,
-- Sanjoy


More information about the llvm-dev mailing list