[llvm-commits] Specification for Run-time Checks

[Santosh Nagarakatte]

John,

>
> I can see how the fastlscheck is useful since it can reduce the
> instrumentation that SoftBound needs to add.  Additionally, the
> pool_register optimizations may be indirectly useful.  If an optimization
> removes a pool_register call for an object, then all of the checks on that
> object can find the bounds of that object without any further
> instrumentation.  SoftBound may be able to take advantage of that.
>


Yes pool_register optimization looks like a good optimization to have.
Is there any documentation of current pool register optimizations.


> I would also argue that lscheck is useful.  The lscheck essentially tells a
> tool where a load/store check must be performed.  Optimizations can remove
> them or hoist them out of loops.  Once that is done, SoftBound can add the
> instrumentation to propagate bounds information and then replace the lscheck
> with the code that checks to see if the pointer is within bounds.
>
> Do you think these ideas will work, or are there problems with them (e.g.,
> would doing things this way make SoftBound more complicated?)?
>

Apart from the checks, SoftBound's overheads are primarily with
propagation. I don't think lscheck/fastlscheck should necessarily
complicate SoftBound

>> Additionally softboundcets would want to pass extra identifier
>> metadata with fastlscheck.
>
> Is this for the CETS instrumentation?  Can a SoftBound-specific pass easily
> enhance the fastlscheck with the needed information?
>

Yes SoftBoundCETS does lock and key checking, needs identifier
metadata with each check.

Thanks
Santosh

-- 
Santosh G Nagarakatte,
PhD Student,
Computer and Information Science Department
University of Pennsylvania,
Philadelphia-19104
http://www.cis.upenn.edu/~santoshn