WebAssembly into normal Target?

Hi All,

WebAssembly has been around for a while now, it’s still being actively worked on and used. I think it’s long past time we make it a normal target so that it gets tested on a regular basis. (Most recent random breakage is https://reviews.llvm.org/rL342576 which fails make check with web assembly enabled).

Any objections? I’ll probably do this next week unless someone raises a strong objection here.

Thanks!

-eric

Sounds reasonable to me.

For reference, these are the targets currently marked experimental:
ARC, AVR, Nios2, RISCV, WebAssembly.

I think RISCV ought to be moved out of the “experimental” list, too.
(cc += asb, for comment)

I agree on RISC-V being pulled out of experimental and into default as well.

Strong +1 on both fronts from me.

Eric Christopher via llvm-dev <llvm-dev@lists.llvm.org> writes:

Hi All,

WebAssembly has been around for a while now, it's still being actively
worked on and used. I think it's long past time we make it a normal target
so that it gets tested on a regular basis. (Most recent random breakage is
https://reviews.llvm.org/rL342576 which fails make check with web assembly
enabled).

If we're at the point where people are asking the committer to fix tests
for the backend, then the backend should definitely be pulled out of
experimental. As is this just leads to needless overhead.

Eric Christopher via llvm-dev <llvm-dev@lists.llvm.org> writes:

Hi All,

WebAssembly has been around for a while now, it’s still being actively
worked on and used. I think it’s long past time we make it a normal target
so that it gets tested on a regular basis. (Most recent random breakage is
https://reviews.llvm.org/rL342576 which fails make check with web assembly
enabled).

If we’re at the point where people are asking the committer to fix tests
for the backend, then the backend should definitely be pulled out of
experimental. As is this just leads to needless overhead.

That was what caused the motivation, but experimental was supposed to be a short term thing and both of these targets have had ongoing and stable maintenance for years now.

-eric

Hi Eric,

We’ve been waiting until we stabilize various key interfaces, including the builtin functions, the C ABI, and the .o file format., as we’d like to avoid having users using packaged versions of LLVM producing C/C++ source files or .o/.a files that end up being incompatible with newer versions of LLVM.

To my knowledge, all of the major issues are fixed now, and the only remaining blocker is that we need to decide what to do here:

https://reviews.llvm.org/D43675 (Rename imported/exported memory symbol to __linear_memory)

Dan

Also this is a good time to discuss buildbots. We’re willing to support a continuous builder that runs WebAssembly-specific stuff if that would be useful. Currently we have wasm-specific code in clang and lld (but since clang doesn’t conditionally compile target support, that’s already being tested), as well as LLVM proper. My understanding is that all of the bots on the default waterfall include a subset of the targets, so it would make sense to add e.g. a clang-wasm-linux or llvm-wasm-linux bot. Assuming that’s true, do folks think it would be best to add something to http://lab.llvm.org:8011/ or would there be a better idea?

+1 to WebAssembly

For RISCV, I’d prefer to see a proposal from Alex, but I could believe we’re ready.

Hi Dan,

Sure. That said I think people are just doing it anyhow :slight_smile:

Hi Eric,

We’ve been waiting until we stabilize various key interfaces, including the builtin functions, the C ABI, and the .o file format., as we’d like to avoid having users using packaged versions of LLVM producing C/C++ source files or .o/.a files that end up being incompatible with newer versions of LLVM.

To my knowledge, all of the major issues are fixed now, and the only remaining blocker is that we need to decide what to do here:

https://reviews.llvm.org/D43675 (Rename imported/exported memory symbol to __linear_memory)

On the bright side we just had a release so you’ll have 6 mos to get that ironed out? :slight_smile:

Anyhow, can’t tell if this is an objection on your part or not?

-eric

RISC-V has a lot of commits going in recently and the quality is improving rapidly. I think that for sure it should become a normal target before the next release. At the moment it’s not quite ready for production use (again that should be in the next few months), but I guess that’s a different question.

So maybe switching it just after the 7.0 release is exactly the right thing to do, to help make sure everything will be ready for the next release.

Right. The idea behind experimental is mostly to:

a) make sure it’s not just a code drop on the community,
b) make sure people care and that it’ll be properly maintained,
c) ensure that the development work on it isn’t going to break anything else.

As far as I can tell while the ports need some work in some places, it’s ongoing and not likely to break anything else in tree. Or at least haven’t broken me and I’m running with them turned on :slight_smile:

-eric

Hi Eric,

Great, thanks! :slight_smile:

I would like to promote it from "experimental" during the 8.0 cycle. I
intend to propose this move between now on the LLVM Dev Meeting.

As to the original topic of this thread. WebAssembly definitely seems
mature enough to promote from experimental. In my view, any backend
that is "stable" at the time of an official release has a certain
obligation with regards to stability of interfaces (command line
interface, object format, assembly, etc etc). It looks like Dan Gohman
answered my question there
<http://lists.llvm.org/pipermail/llvm-dev/2018-September/126261.html&gt;
and things are now fairly fixed.

Best,

Alex