[LLVMdev] LLVM Language Reference Strictness
shea at shealevy.com
Thu Oct 20 02:37:53 PDT 2011
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,
More information about the llvm-dev