[llvm-commits] [llvm] r157261 - in /llvm/trunk: include/llvm/InitializePasses.h include/llvm/LinkAllPasses.h include/llvm/Transforms/Scalar.h include/llvm/Transforms/Utils/Local.h lib/Transforms/InstCombine/InstCombine.h lib/Transforms/InstCombine/InstCombineAddSub.cpp lib/Transforms/InstCombine/InstructionCombining.cpp lib/Transforms/Scalar/BoundsChecking.cpp lib/Transforms/Scalar/Scalar.cpp

[Duncan Sands]

Hi John,

>> A possible solution is to introduce a new readnone intrinsic "llvm.identity"
>> which simply returns its argument but is opaque to the optimizers. You then
>> insert
>
> Duncan, would the llvm.identity intrinsic be useful for other things, or is it
> only useful for this particular application?

I originally came up with this concept in order to solve similar but broader
problems with Ada: bounds checks, integer overflow checks and other compiler
checks need to work even for uninitialized variables (undef) etc.  The problem
however is that the GCC Ada front-end outputs these using regular compares,
arithmetic and branches (relying on the details of how GCC handles uninitialized
values to work), and there is no obvious way for dragonegg to recognize these
and turn them into undef safe code.  That's why I never implemented
llvm.identity.  This is a rather nasty flaw in LLVM's Ada support.

> The SAFECode checks in my proposal do not suffer from this problem because the
> comparisons are hidden away within the run-time check functions.

Right, that is an alternative solution, however it relies on having a library
of checking functions that is always fairly opaque to the optimizers (eg the
library functions should not be inlined into the call sites), so no LTO, or at
least inlining has to be turned off, which seems a pity.  With llvm.identity
you get a simple primitive on which checks can safely be built inline.  You
could get the same effect using a single opaque library function "identity"
but making it an intrinsic seems natural, especially as you probably want one
for each integer type (when doing arithmetic overflow checking).  I think
it's a nice solution.  Possibly it would allow better optimization of checks
too, especially for repeated checks or when more than one check (which in your
scheme are distinct library functions) performs mainly the same computation:
with the llvm.identity scheme the commonality might be exploited by the
optimizers.  However that's just speculation.

Ciao, Duncan.