[LLVMdev] LLVM Language Reference Strictness

[Shea Levy]

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?
>> 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