Generating Javascript or asm.js from LDC?

[David Nadlinger via digitalmars-d-ldc]

Hi Laeeth,

On 5 Sep 2015, at 17:15, Laeeth Isharc via digitalmars-d-ldc wrote:
> 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.

> 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'

Seems like Emscripten uses 32 bit pointers whereas you compiled the D 
sources for a 64 bit target.

> 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'

You could easily make LDC emit a different target triple. I'm not sure 
whether asmjs/emscripted are recognized by LLVM by default, but if so, 
it's as simple as using the -mtriple argument or hacking the code in 
ldc/driver/targetmachine.cpp (just search for "triple"). If not, there 
is probably an Emscripten patch to LLVM that adds support.


> 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

Looks like emscripten either expects frontends not to generate "byval" 
parameters, or there is some kind of previous pass you are supposed to 
run (probably "ExpandByVal", from the error message) to lower them.

— David