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>
