search for: wasm32

...ltin library generated (libclang_rt.builtins-x86_64.a). Taking a look in a cmake config file from compiler-rt, I saw that ppc64 is not in the supported architecture list to generate the builtin library: set(ALL_BUILTIN_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64} ${MIPS32} ${MIPS64} ${WASM32} ${WASM64}) But in compiler-rt webpage (https://compiler-rt.llvm.org/), under "Platform Support", says: "builtins is known to work on the following platforms: - Machine Architectures: i386, X86-64, SPARC64, ARM, PowerPC, PowerPC 64." Shouldn't the builtin library be bu...

Hi, Sorry if you've seen this message before on llvm.discourse.group or elsewhere -- I've been trying to get to the bottom of this for a while now and asked about this in a few different platforms before. I'm currently trying to debug a bug in a LLVM-generated Wasm code. The bug could be in the code that generates LLVM (rustc) or in the LLVM, I'm not sure yet. LLVM IR and Wasm

...orce enable int128_t support during building > compiler-rt for rv32. > > Any other suggestion? As a point of information, it would be useful to know if there are any major drawbacks or challenges to adding __int128_t support to GCC for RV32. Looking at Clang, it seems (by my reading) that Wasm32 is the only 32-bit target supporting __int128_t (though x86-64 with 32-bit ABI and Mips64 with 32-bit ABI also support it). Given that `long double` is 128 bits on both RV32 and RV64, __int128_t wouldn't be the only 128-bit type. Best, Alex

Hi all: I'm porting RISC-V[1] for compiler-rt recently, and I've got a problem when adding soft float routine for rv32, RISC-V ABI required 128 bits bits for long double, but it's implemented by int128_t, however rv32 don't support __int128_t. Of cause, it not hard thing to support __int128_t by overriding TargetInfo::hasInt128Type for LLVM, but its will cause some ABI

....wasm can be interpreted without worrying about a helper. I had to use -nostdlib and -nostdinc in my build script but I wished the llvm-libc initiative can make it simpler so I don't have to put together a minimal libc for my need. Something similar can be achieved in Rust world using --target wasm32-unknown-unknown e.g. [3] which I guess can be best lead here also in terms what can be in scope of this work. [1]: https://github.com/harfbuzz/harfbuzzjs/tree/edf1d8b/libc [2]: https://github.com/harfbuzz/harfbuzzjs/blob/gh-pages/stb-image/index.html [3]: https://github.com/RazrFalcon/ttf-parse...

Cause llvm-libc are in early stage, and we can easily catch up the support with linux. After we add wasi support in llvm-lic, we can easily get a usable llvm-libc across different platform such as linux/windows/macos/android. don't know if iOS is a target, but these target are very much enough -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -------------- next part -------------- An

On Sat, Mar 12, 2016 at 2:38 PM, Tim Northover <t.p.northover at gmail.com> wrote: > On 12 March 2016 at 11:51, Rail Shafigulin via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I tried every possible combination of --target I could think of but > nothing > > worked. Would you mind helping me out? > > First, 64-bit x86 is "x86_64", and 32-bit

Hi llvmers, As you may know, work has been progressing on the experimental WebAssembly backend in llvm. However, there is currently not a good linking story. Most the of existing linking strategies (i.e. those in the emscripten toolchain) involve bitcode linking and whole program compilation at link time. To improve this situation I've been working on adding a wasm backend for lld. My

Can you link to docs about the wasm object format? (both relocatable and executable) Also, traditional object file linkers are primarily concerned with concatenating binary blobs with small amount of patching of said binary blobs based on computed virtual (memory) addresses. Or perhaps to put it another way, what traditional object file linkers do is construct program images meant to be mapped

Hello everyone, We're a little bit behind schedule, but RC1 is now here. It was tagged earlier today as llvmorg-11.0.0-rc1. Source code and docs are available at https://prereleases.llvm.org/11.0.0/#rc1 and https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc1 Pre-built binaries will be added as they become available. Please file bug reports for any issues you find as