[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