[LLVMdev] LLVM Language Reference Strictness

[Dan Gohman]

On Oct 19, 2011, at 8:58 PM, Eli Friedman wrote:

> On Wed, Oct 19, 2011 at 8:20 PM, Shea Levy <shea at shealevy.com> wrote:
> 
>> 4. Are any behaviors undefined by virtue of not being specified in the
>> reference, or are all scenarios that lead to undefined behavior
>> explicitly identified as such?
> 
> We really want to explicitly identify them all in the reference; if
> you have a question about some specific case, please ask.


However, there is a ton of stuff that's not explicitly identified today.

For example, consider a call to a function address bitcasted to a type
incompatible with the type of the function.  Most of us around here intuitively
know this gets undefined behavior because we know how to think like a C
compiler. But LangRef doesn't discuss this. It doesn't even have a concept
of "compatible" types with which to discuss it.

What should the rules be?  If we look through LLVM's source code, we
find that the inliner has code for smoothing over caller/callee mismatches.
However, we can't translate this logic into LangRef because it does things
that are impossible to do for non-inlined calls in most backends.  If we
dig through every backend, we could come up with a minimal set of
functionality that could be broadly supported.  However, this set would be
too minimal for clang, for example, which regularly bitcasts objc_msgSend
in ways that it knows will work, but only for non-obvious reasons.

You could spend weeks researching all the nuances of just this problem.
In practice, LLVM just doesn't worry about it.  Problems like this tend to be
edge cases that don't cause trouble for most people most of the time.
However, you can find them all over the place if you go looking.

Dan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111020/3d49e61a/attachment.html>