Generating Javascript or asm.js from LDC?

[Laeeth Isharc via digitalmars-d-ldc]

On Saturday, 5 September 2015 at 01:32:43 UTC, Adam D. Ruppe 
wrote:
> On Friday, 4 September 2015 at 18:47:06 UTC, Laeeth Isharc 
> wrote:
>> Is this by any chance possible?
>
> I'm not entirely sure myself, but my theory is if you can feed 
> the llvm code out of ldc and into the emscripten backend... the 
> basics should just work, D can pretend to be C, and we build up 
> from there. Indeed, the whole D runtime might even build - if 
> we're really lucky - since some Linux functions are apparently 
> supported by emscripten.
>
> But I haven't actually tried doing it.

Fwiw I tried it, not really expecting much.  It didn't work, and 
I'm not sufficiently familiar with clang and llvm to understand 
the meaning of the errors.

import core.stdc.stdio;

void main()
{
	printf("hello");
}

ldc -O0 test2.d --output-bc
emcc test2.bc -O0 -v

INFO     root: (Emscripten: Running sanity checks)
WARNING: Linking two modules of different data layouts: 
'/home/laeeth/.emscripten_cache/libc.bc' is 
'e-p:32:32-i64:64-v128:32:128-n32-S128' whereas 'llvm-link' is 
'e-m:e-i64:64-f80:128-n8:16:32:64-S128'

WARNING: Linking two modules of different target triples: 
/home/laeeth/.emscripten_cache/libc.bc' is 
'asmjs-unknown-emscripten' whereas 'llvm-link' is 
'x86_64-unknown-linux-gnu'

WARNING: Linking two modules of different data layouts: 
'/home/laeeth/.emscripten_cache/dlmalloc.bc' is 
'e-p:32:32-i64:64-v128:32:128-n32-S128' whereas 'llvm-link' is 
'e-m:e-i64:64-f80:128-n8:16:32:64-S128'

WARNING: Linking two modules of different target triples: 
/home/laeeth/.emscripten_cache/dlmalloc.bc' is 
'asmjs-unknown-emscripten' whereas 'llvm-link' is 
'x86_64-unknown-linux-gnu'

PAL[
   { 1 => byval }
   { ~0U => uwtable }
]
LLVM ERROR: Attribute should already have been removed by 
ExpandByVal
Traceback (most recent call last):
   File "/usr/lib/emscripten/emcc", line 1271, in <module>
     shared.Building.llvm_opt(final, link_opts)
   File "/usr/lib/emscripten/tools/shared.py", line 1412, in 
llvm_opt
     assert os.path.exists(target), 'Failed to run llvm 
optimizations: ' + output
AssertionError: Failed to run llvm optimizations:


====
I don't know, but looks like they modified clang too:
https://github.com/Laeeth/emscripten-fastcomp-clang

some colour here:
https://kripken.github.io/emscripten-site/docs/contributing/developers_guide.html#developer-s-guide