[llvm-commits] Specification for Run-time Checks

[John Criswell]

On 5/14/12 10:37 AM, Nuno Lopes wrote:
> Hi John et al.,
>
> I read your proposal and all emails in the discussion.
> I must say that, for now, this proposal goes a bit too far for our 
> purposes.
> Our idea is to have both quick checks and a fast implementation on the 
> compiler side. Your proposal introduces quite a lot overhead a priori.

By "lots of overhead," do you mean overhead during compilation or 
overhead in the generated program?

Either way, I don't see how my proposal has any more overhead.  If it's 
the former, I don't see how your proposal is any faster at compile time 
than mine.  Both proposals have Clang inserting checks everywhere (in 
your case, objectsize checks, and in my case, lschecks), and both 
proposals have an LLVM-based mechanism that removes the checks that are 
too expensive to do at run-time.

If it's the latter, then I don't see why your proposal will generate 
more efficient code.  If I understand correctly, fastlscheck is 
equivalent to the run-time checks that you propose to add using 
objectsize; the implementation of fastlscheck can be inlined just as 
your system proposes to do.

Please let me know if I'm misunderstanding something, but I don't see 
how your system is inherently faster.  Both proposals appear to do the 
same thing; whichever one is faster seems like a matter of implementation.

> We would prefer a more lazy approach. I think you/we could apply your 
> strategy after we lower most of the objectsize calls. The remaining 
> ones will be the ones that we don't know how to implement efficiently, 
> and therefore they need more heavyweight techniques like the ones 
> you're proposing.

I do not believe that this is a good approach.  The problem is that the 
common run-time check instrumentation pass would need to determine which 
pointers have been checked by your checks and which ones have not.  That 
adds unneeded complexity.  I think it's better to add all the checks at 
once and then optimize/remove them as needed.

There is also the problem that certain optimizations and checks may be 
desirable for one tool but not another.  For example, does objectsize 
care about whether a malloc'ed object could have been freed between the 
allocation and the check?  Some tools may want to try to catch this 
error with a run-time check; others may make dangling pointer 
dereferences safe by using pool allocation; still others might use 
garbage collection.

Your design, as I understand it, will hard-code one of those design 
decisions into how objectsize works.  My design, in contrast, allows 
different tools to choose which checks to add and which optimizations 
out of a common set to use.

> That way you can focus only on the difficult cases, letting the 
> compiler discharge the trivial ones for you.  We'll be implementing 
> optimizations for objectsize as well.

Why not reuse the optimizations that we built for SAFECode?  The common 
infrastructure I proposed is derived from SAFECode's design; several 
robust optimizations already exist, and one or two others (like 
monotonic loop hoisting) just need some TLC to make them ready for prime 
time.

-- John T.