Attempt to specify externref as a pointer type with a fixed size of 32, instead of opaque.

Fix getLegalType for simple MVTs

This is very, very WIP patch implementing LLVM IR support for global.get/set.

In D91428#2413292, @pmatos wrote:

Thanks, @arichardson and @jrtc27 for your comments.
I am definitely surprised to find that if you explicitly mark the call with the address space, this patch is not required. At first look, this RFC is not required any more but I need sometime to investigate further. If no changes are necessary, this is indeed good news.

Thanks, @arichardson and @jrtc27 for your comments.
I am definitely surprised to find that if you explicitly mark the call with the address space, this patch is not required. At first look, this RFC is not required any more but I need sometime to investigate further. If no changes are necessary, this is indeed good news.

The RFC has now been sent to the mailing list: http://lists.llvm.org/pipermail/llvm-dev/2020-November/146723.html

Fix type check.

Ensure the program address spaces vector doesn't contain duplicates.

This is WIP - there a still a few test failures but I am happy to start getting comments on this.

@sbc100 if it's ok for you, feel free to merge, thanks.

Align with local indent style

Remove unused operand type.

Is this good to merge?

Regarding linter clang-format suggestions - should I reformat the code as suggested or leave it?
Some suggested changes are not necessarily on code I wrote, which is why I ask.

These changes reflect the first set of comments. High on the list is quite a few changes related to setting registers for funcrefs and externrefs. A few things might not be strictly necessary but pave the way for future work.

Thanks for the review - I will submit a new revision.

So the goal here is to add most of the table instructions. This introduces some table relocations, which (in a following patch) we will resolve in the linker.

Further test fixes - missing index

In D88815#2326785, @pmatos wrote:

In D88815#2326737, @sbc100 wrote:

I seeing:

llvm-project/llvm/lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp:111:11: warning: enumeration value 'FUNCREF' not handled in switch [-Wswitch]
  switch (VT) {

Oh, I was not getting that. It seems to come from https://github.com/llvm/llvm-project/commit/3bba91f64eef15956f589fa446c265a714cc7893 and I hadn't pulled that in yet. If I rebase my patch on this then yes, I can see the warning. i will fix it in this patch. No worries.

Fix warning due to missing FUNCREF in switch

In D88815#2326737, @sbc100 wrote:

I seeing:

llvm-project/llvm/lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp:111:11: warning: enumeration value 'FUNCREF' not handled in switch [-Wswitch]
  switch (VT) {

Fix a bunch more lld tests to include index for tables

In D88815#2325730, @sbc100 wrote:

Is this ready to land now?

Fix tests to include table index in expected dump

Fix build failure

Move Index to first position in WasmTable struct

Fix review nits

Thanks for the reviews. I will fix the nits mentioned and update the revision.

In D88226#2292764, @sbc100 wrote:

This is already supported like via -mllvm. E.g. wasm-ld -mllvm -debug or wasm-ld -mllvm -debug-only=lld

Update externref patch

Mistakingly created - this should have gone to D66035

In D66035#2181659, @pmatos wrote:

I will be splitting the part enabling the target feature through clang into a separate revision as suggested by @tlively

I will be splitting the part enabling the target feature through clang into a separate revision as suggested by @tlively

Update patch to compile against current master branch

Related work: https://reviews.llvm.org/D81977

There's also this line of work on opaque types that could be potentially interested but seems far from being landed: https://groups.google.com/g/llvm-dev/c/Dw_DYSXGFto/m/OzzK-CkGAwAJ

Please ignore my .gitlab-ci.yml. That's just an internal change that I got uploaded by mistake.
I am looking to see this through and start discussion on this with the goal of landing it.

Initial implementation of reference types in the WebAssembly backend

In D66035#2175906, @vchuravy wrote:

In D66035#2175839, @pmatos wrote:

I am interested in continuing this work and have a patch in progress based on the current available one here. Should I post the new patch here or under a new bug?

Feel free to commandeer this revision

I am interested in continuing this work and have a patch in progress based on the current available one here. Should I post the new patch here or under a new bug?

Was this ever fixed and reapplied? The last I can find on this was r313057 where @rob.lougher reverted r313047.

I should point out that r289661, which is part of the 8 patches, does not show up in the review commit list.

Added missing testcase to previous patch.

@efriedma I have uploaded a new patch taking your comments into consideration and rebased on most recent clang sources.

Thanks for the comments.

Apologies for leaving this for so long. Are there any further comments?
How do we get this upstream given I don't have commit rights?

Here's an updated patch including the test. Hope this is now ok for submission. Please accept my apologies with regards to the delay in submitting this.

Ah no, my mistake. I had the patch applied when I ran the test.

Has this been fixed upstream already?

Apologies for the delay over the holiday season, I will look into this later on after office hours.

Can someone please take a look at this one?

This is not supposed to be marked as accepted.

Abandoning this revision.

Please refer to the new one: https://reviews.llvm.org/D27800

@efriedma Here's the new patch, thanks for your help getting here.

OK, with a lot of help from @eli.friedman I have now a fix. Shall I reuse this review by submitting a new diff or open a new one?

Apologies if I am being shallow and wasting your time but sizeof(T::m) doesn't compile at the moment with clang trunk. Using the same service you used before.

In D26843#599673, @EricWF wrote:

But that is not valid in C afaik and in C++ I get:

error: invalid use of non-static data member 'm'
  int x = sizeof(T::m);
                 ~~~^

Can you post a full reproducible example of what the change breaks?

That is a full reproducible example because it's valid C++. Clang currently compiles it.

In D26843#599635, @EricWF wrote:

This isn't correct. For example this change breaks:

struct T { int m; };
int x = sizeof(T::m);

To the reviewers:
I believe there's a better way to handle this. However, I would like to know if this approach is a good one or the reviewers find that there's a much better way to do this and I took it in the wrong direction.