[LLVMdev] Newbie questions

[Chris Lattner]

On Mon, 24 Apr 2006, Archie Cobbs wrote:
> The idea of the optimizer computing that a trap can't happen is obviously
> desirable, but how does the front end tell the optimizer how to figure

It depends on the front-end.  If you're coming from C, there is no good 
way.  C can't express these properties well.  However, this this specific 
case:

> that out? I.e., consider this java:
>
>  void foo(SomeClass x) {
>    x.field1 = 123;
>    x.field2 = 456;      // no nNullPointerException possible here
>  }
>
> Clearly an exception can happen with the first statement -- iff x is null.
> But no exception is possible on the second statement. But how does the
> optimizer "know" this without being Java specific?

This isn't specific to Java.  LLVM pointers can't wrap around the end of 
the address space, so if the first access successed, the second must also. 
LLVM won't guarantee exceptions for bogus pointers, just null pointers, so 
it could do this without a problem.

> Another random question: can a global variable be considered variable
> in one function but constant in another?

No.

> Motivation: Java's "first active use" requirement for class initialization.
> When invoking a static method, it's possible that a class may need to
> be initialized, However, when invoking an instance method, that's not
> possible.

You need to modify the isConstant flag on the global after the initializer 
has been run.  This requires JIT compilation.  Note that the LLVM 
optimizer should already do a reasonable job of optimizing some common 
cases of this, as a similar thing happens when initializing C++ static 
variables.

> Perhaps there should be a way in LLVM to specify predicates (or at least
> properties of global variables and parameters) that are known to be true
> at the start of each function... ?

We don't have something like this currently.  It sounds tricky to get 
right.

> Trying to summarize this thread a bit, here is a list of some of the
> issues brought up relating to the goal of "best case" Java support...
>
> 1. Definition and clarification of the memory model.
> 2. Need some instructions for atomic operations.
> 3. Explicit support for exceptions from instructions other than invoke.
> 4. Ensuring there are mechanisms for passing through all appropriate
>    optimization-useful information from the front end to LLVM in a
>    non-Java-specific way (e.g., see "active use" check above).

Yup.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/