[LLVMdev] Newbie questions

[Chris Lattner]

On Sun, 23 Apr 2006, Reid Spencer wrote:
>> My area of interest is using LLVM in a Java JVM setting. These are
>> just some random questions relating to that...
>>
>> 1. What is the status of the LLVM+Java effort?
>
> Incomplete but significant progress has been made. Misha Brukman can
> tell you more.

There are actually two different LLVM + Java projects.  The 'llvm-java' 
project, developed primarily by Alkis Evlogimenos <alkis at evlogimenos.com>, 
is in LLVM CVS.  It has basic stuff working, but is far from complete.  It 
is also stalled: noone is working on it any longer.

The second project is a LLVM JIT backend to GCJX.  GCJX (developed by Tom 
Tromey) is far more complete, but the LLVM backend is quite new.

>> 2. I'm curious why the LLVM language includes no instructions for memory
>>     barriers or any kind of compare-and-swap (bus locking operation). Were
>>     these considered?
>
> Yes.

Someone did actually develop intrinsics for these, but they were never 
contributed back to LLVM.

>> What about
>>     some definition of the atomicity of instructions (e.g., is a write of
>>     a 32 bit value to memory guaranteed to be atomic)? More generally does
>>     the LLVM language define a specific (at least partial) memory model?
>
> Currently the language doesn't support atomic instructions. However,
...
> LLVM repository yet. I'm not sure of the status at UIUC of this effort,
> as it hasn't been discussed in a while. It is definitely something that
> will be needed going forward.

My understanding is that it is stalled.  If someone wanted to do something 
regarding this, it would be quite welcome.  In particular, for atomic 
operations, starting with implementation of the new GCC atomic builtins 
would make a lot of sense.

>>     To give an example (perhaps this is not a real one because possibly it
>>     can already be captured by LLVM alone) is the use of a Java final instance
>>     field in a constructor. In Java we're guaranteed that the final field is
>>     assigned to only once, and any read of that field must follow the initial
>>     assignment, so even though the field is not read-only during the entire
>>     constructor, it can be treated as such by any optimizing transformation.
>
> LLVM would already recognize such a case and permit the appropriate
> optimizations.

This specific optimization can also be easily handled in a LLVM JIT 
environment.

-Chris

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