[LLVMdev] LLVM Language Reference Strictness
Shea Levy
shea at shealevy.com
Wed Oct 19 20:20:21 PDT 2011
Hello,
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
itself?
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?
Thanks,
Shea Levy
More information about the llvm-dev
mailing list