[LLVMdev] LLVM Language Reference Strictness

Shea Levy shea at shealevy.com
Wed Oct 19 20:20:21 PDT 2011


I'd like write a program that performs static analysis of code at the 
LLVM assembly/bitcode level, and to do so I plan on extensively 
referencing the language reference. As I hope to eventually use this 
tool as part of a security analysis of untrusted code, I need to be 
rather strict in my interpretation of the document. As such, I have some 
questions about how the implementers interpret the document (each 
question assumes we're considering a single fixed release version):

1. Is http://www.llvm.org/releases/<version>/docs/LangRef.html the most 
authoritative reference for a given version aside from the source code 

2. Are target-specific behaviors documented for each supported target?

3. Does undefined behavior semantically invalidate the entire program or 
is its unpredictable effect limited in scope somehow?

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?

5. Are there any language features with non-performance related semantic 
import (e.g annotations, instructions, intrinsic functions, types, etc.) 
that are not specified by the reference but are nevertheless implemented 
in the build system?

6. Are all deviations from the reference, no matter how minor, 
considered bugs (either in the implementation or the spec)? If not, what 
deviations are considered acceptable? If so, is it expected that all 
such discovered and possibly corrected deviations will have associated 
bug reports, or might some be corrected in the development repository 
without documentation of the issue outside of a commit message? In other 
words, if I'm working with, say, llvm 2.9 and want to find all 
deviations known to upstream, can I just browse bug reports or will I 
have to go through commit logs as well?

These are the questions I have for now, but I may have more as I go 
along. Is this the appropriate place to ask this kind of thing?

Shea Levy

More information about the llvm-dev mailing list