merging in llvmdc runtime

updated patch to reflect changes in the llvmdc repository, I've just removed our local copy and now rely on applying the attached patch to a svn checkout.

I've decided to change LLVMDC so that 80bit floats are always used for the 'real' type. This fixes a bunch of issues and complies with the spec. Cleaned up the patch a bit, though more can probably be done with improved (automatic?) intrinsic detection/handling.

Feedback is much appreciated.

Don: Maybe you can look at the Math changes?

Those math changes look OK to me. Actually, those same functions could use some work in the DMD case! I'm not certain the DMD intrinsics always work properly.

updated patch for rev [3899]

llvmdc's inline asm and intrinsic support has improved a bit so patch updated.

This time it includes a reimplementation of core.Atomic using llvm atomic intrinsics. The implementation is probably incorrect, at least the unittest fails, but I'm unsure how it should really look, the casting is because llvm only supports atomics on integers of 8,16,32 and 64 bits.

It will currently fail on architectures that don't implement that intrinics to there types.

Regarding the existing X86 implementation, It doesn't work due to missing 'ret' instructions, I don't see anywhere in the spec stating that falling off the end of a function implicitly add a ret, preserving EAX etc. In LLVM, the inline asm will end, and llvm will take over, inserting its own ret instruction and overriding the return value computed in the inline asm.

We could really use some testing of our inline asm support by someone who knows it well. While work on ABI compiliance has only just begun, it's something I'm very interested in fixing.

Regarding the existing X86 implementation, It doesn't work due to missing 'ret' instructions, I don't see anywhere in the spec stating that falling off the end of a function implicitly add a ret, preserving EAX etc. In LLVM, the inline asm will end, and llvm will take over, inserting its own ret instruction and overriding the return value computed in the inline asm. 

If the function is 'naked', then the programmer needs to add 'ret'. Otherwise, the compiler is responsible for setting up and ending the stack frame (if any), which includes the ret.

Please don't make GDC's mistake of declaring D_InlineAsmX86 before the D ABI is supported! Is there a LLVM which will work on Win32?

I've updated the patch again, as some of the changes last time was broken.

Basically, LLVM does not support splitting asm blocks. This means a call can't be wrapped in two asm blocks with pushad/popad. I've been talking to the LLVM developers about this and it's not going to change.

I don't see anywhere in the spec where it says that this is actually allowed either so it's not too bad imho.

We do have a LLVMDC for Win32, but there's problems with inline asm specifically, as well as exception handling not implemented at all... Elrood has been kind enough to make an installer available, if you still want to take a look, however, I'm not sure how up to date it is.

We do currently define D_InlineAsmX86, and I'm not sure I want to remove that, Don, see my comment on the ticket for GDC on this issue.

the win32 installer is here: http://incasoftware.de/~elrood/

made a few mistakes in the patch "revert"

We do currently define D_InlineAsmX86, and I'm not sure I want to remove that, Don, see my comment on the ticket for GDC on this issue.

And see my reply. That MUST be changed. It's a misreading of the spec page to believe that the ABI is optional. It is IMPOSSIBLE to write inline asm if you don't know what the calling convention is.

A status update: we have removed D_InlineAsmX86 (replaced by LLVM_InlineAsmX86) and made naked an error. Tomas continues to work on supporting the D ABI.

Cool. I'll "accept" this ticket and wait for your say-so before applying changes.

We're getting closer to the next Tango release - unless work starts now, I don't think there is much point in trying this before the release?

I have attached the remaining changes to Tango LDC requires. Some (minor) changes had been filed separately as #1309. The patches are split by topic, though I just noticed part of the gc change slipped into tango-common.patch, instead of being in tango-gc.patch.

Most of them should not require further discussion, however there are also:

• some of fawzi's darwin changes that are not yet in tango
• slightly ugly changes to tango.math
• slightly ugly workarounds for the lack of 'naked' in LDC in Thread.d

Are the math.IEEE changes still required? I think I fixed them. The other ones mostly look like support for intrinsics, which actually don't even work for DMD! But I think they can be folded in as-is... provided they are still current.

The IEEE changes were part of fawzi's darwin patch. If you think you already fixed it, don't apply them - they're optional.

Indeed the IEE changes, atomic changes, and a couple of other changes are not needed. I had a very busy week, but this w.e. I plan to test everything well and see what to check in

the atomic stuff already in tango could probably work on x86 for ldc, however, using llvm's atomic intrinsics, we can have one implementation that will eventually work on all llvm targets that support them, also the code generators/optimizers understand theses intrinsics, and can do stuff like inlining, which is impossible when asm is used.

tango-build.patch applied (with minor changes) in r4169

tango-atomic.patch, tango-common.patch, tango-gc.patch, tango-misc.patch can be applied as they are

(In [4171]) LDC atomic implementation refs #1212

(In [4172]) LDC patch refs #1212

(In [4173]) LDC patch refs #1212

fix for build-tango.sh

Thanks for applying these! The modifications to build-tango.sh don't work though - $LDC is always unset. I attached a fix.

(In [4174]) LDC patch fixes refs #1212

(In [4175]) LDC patch fix (ChristianK) fix #1212