[LLVMdev] Question about Value Range Propagation

[Peter Lawrence]

Chris,
            one way to look at array bounds check optimization, and  
the value range propagation that it can be based on, is that it's  
usefulness is language dependent.  Ada and Java benefit from it  
greatly, C/C++ not at all, but then a "codesafe" version of C/C++  
would, as John T was pointing out below.

It seems like the software engineering modularity of llvm's various  
analysis and transform phases lends itself to having phases that fit  
this description, worthwhile to have, but not necessarily linked in  
and/or not necessarily invoked, for every front end language.

Another approach is to only trigger the analysis/transform if any  
bounds check instructions have been encountered, which won't happen  
in traditional C/C++.

Are either of these approaches consistent with your design philosophy ?

thanks,
Peter Lawrence.


(ps, the possible performance problem with the previous ABCD should  
not be a factor in the above, since while I don't yet know why that  
implementation suffered, or if it even did, I do know from personal  
experience that VRP/ABCD can be both very efficient and very effective.)



On Feb 22, 2011, at 4:46 PM, llvmdev-request at cs.uiuc.edu wrote:

>> the big problem with Patterson's VRP is that it is expensive in  
>> terms of
>> compile time.  LLVM used to have some passes (ABCD, predsimplify)  
>> that did
>> this kind of thing, but they were removed essentially because  
>> their compile
>> time was too great for the goodness they brought.
>
> I was under the impression that ABCD was removed because no one was
> maintaining and improving it.  Is my impression incorrect?
>
> The SAFECode compiler adds additional run-time checks for array bounds
> checking.  If the ABCD code was working but just wasn't useful for
> regular C code, I'd like to know.  It may still have value for  
> projects
> like SAFECode.
>
> -- John T.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110304/210de728/attachment.html>