[LLVMdev] LLVM Language Reference Strictness

[Jim Grosbach]

On Oct 20, 2011, at 2:37 AM, Shea Levy wrote:

> On 10/19/11 11:58 PM, Eli Friedman wrote:
>> On Wed, Oct 19, 2011 at 8:20 PM, Shea Levy<shea at shealevy.com>  wrote:
>>> 2. Are target-specific behaviors documented for each supported target?
>> When anything has target-specific behavior, that fact should be
>> documented.  Beyond that, if you have a question about what some
>> construct is supposed to do, please ask.
> What I meant was: for a given target-specific behavior, is there 
> anywhere I can look to see what the behavior specifically is for, say, 
> i686-pc-linux, like you are supposed to be able to for 
> implementation-defined behaviors in C?

For the level of specificity you're looking for, just the source code itself. The LLVM IR language documentation is not, and isn't intended to be, a true language standard document in the same way that the C or C++ standards are. For any given case, check the docs first, and if your question isn't answered there, check the source code of the target(s) you're interested in.

Regards,
  Jim

>>> 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?
>> You should be able to analyze the semantics of IR accurately based
>> purely on information encoded into the IR.  Every instruction, type,
>> attribute etc. should be documented in LangRef.  Platform-specific
>> intrinsics are not documented, but can generally be treated like a
>> call to an external function.
> Platform-specific intrinsics are not documented anywhere, or just not in 
> the language reference?
>>> 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?
>> LLVM Bugzilla doesn't contain an entry for every bug; to find every
>> fix, you'll have to go through commit logs.  Not sure what you're
>> trying to do here, though.
> Some more detail on my project: I'm mostly doing this so I can get 
> introduced to the field of static analysis, learn what it's big problems 
> are and what's just impossible with it, etc. To that end, however, I've 
> decided to try to implement a set of checks that might actually be 
> useful, to me at least. In particular, I want to see how many of the 
> run-time checks made in hardware when a CPU is in user-mode and memory 
> is segmented can be proven to be unnecessary at compile-time. The 
> (probably impossible) end-goals to this project would be a) that every 
> program which passes its checks would be as safe to run in kernel mode 
> with full memory access as it would be in user mode and b) that a 
> not-insignificant subset of well-written programs passes its checks. If 
> I ever reach the point that I'm actually using this thing to run 
> untrusted code in kernel mode, I'll want to know about as many 
> deviations from the spec as possible to know if they might affect the 
> reasoning my program uses.
> 
> Thanks for the help,
> Shea Levy
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev