This is an archive of the discontinued LLVM Phabricator instance.

[WebAssembly] Implement ref.null
ClosedPublic

Authored by wingo on Nov 2 2020, 6:51 AM.

Details

Summary

This patch adds a new "heap type" operand kind to the WebAssembly MC
layer, used by ref.null. Currently the possible values are "extern" and
"func"; when typed function references come, though, this operand may be
a type index.

Note that the "heap type" production is still known as "refedtype" in
the draft proposal; changing its name in the spec is
ongoing (https://github.com/WebAssembly/reference-types/issues/123).

The register form of ref.null is still untested.

Diff Detail

Event Timeline

wingo created this revision.Nov 2 2020, 6:51 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 2 2020, 6:51 AM
wingo requested review of this revision.Nov 2 2020, 6:51 AM
wingo added a subscriber: pmatos.Nov 2 2020, 6:52 AM

This is baby's first LLVM patch; beyond the review itself, any meta-tips and feedback are very welcome!

Nice! This looks good besides that one question. Also, for the patch description, it seems slightly misleading to say that "the register form of ref.null is still unimplemented"; IIUC, the register form is implemented since the I tablegen multiclass creates both forms, but it's simply not used for anything right now.

Since this is your first LLVM patch, I assume you don't have commit access to LLVM yet? If so, I can land this for you. After a couple more patches, you should request commit access.

llvm/lib/Target/WebAssembly/AsmParser/WebAssemblyAsmParser.cpp
584

Is this last line necessary? It looks like the other cases don't have similar lines.

lgtm. In a project that primarily deals with C/C++ code I find "heap time" a little confusing because it makes me think of the malloc heap used by C/C++. Why not "managed" or something like that to avoid ambiguity? I guess that is being discussed in the spec and we should probably just follow their lead.

lgtm. In a project that primarily deals with C/C++ code I find "heap time" a little confusing because it makes me think of the malloc heap used by C/C++. Why not "managed" or something like that to avoid ambiguity? I guess that is being discussed in the spec and we should probably just follow their lead.

I do think that matching the upstream spec "heap type" terminology is important, even if it's a little confusing in a C++ context.

sbc100 added a comment.Nov 2 2020, 1:07 PM

lgtm. In a project that primarily deals with C/C++ code I find "heap time" a little confusing because it makes me think of the malloc heap used by C/C++. Why not "managed" or something like that to avoid ambiguity? I guess that is being discussed in the spec and we should probably just follow their lead.

I do think that matching the upstream spec "heap type" terminology is important, even if it's a little confusing in a C++ context.

Do you think that upstream term "heap type" is reasonable, given the pre-existing alternate meaning of heap that already exists in the unmanaged world?

lgtm. In a project that primarily deals with C/C++ code I find "heap time" a little confusing because it makes me think of the malloc heap used by C/C++. Why not "managed" or something like that to avoid ambiguity? I guess that is being discussed in the spec and we should probably just follow their lead.

I do think that matching the upstream spec "heap type" terminology is important, even if it's a little confusing in a C++ context.

Do you think that upstream term "heap type" is reasonable, given the pre-existing alternate meaning of heap that already exists in the unmanaged world?

I've gotten used to that name, so I don't personally have any problems with it. I definitely see the potential for confusion, though. I hope it won't be too bad in practice because it will usually be clear from context whether "heap type" means a WebAssembly heap type or if it means something to do with the C++ heap.

wingo updated this revision to Diff 302483.Nov 3 2020, 12:08 AM

Address feedback.

wingo added a comment.Nov 3 2020, 12:12 AM

Thanks for review, Thomas and Sam! Addressed feedback. Thanks also for the tips regarding commit access; for the time being if it looks good to you, would you mind landing this one, @tlively ? Cheers!

wingo edited the summary of this revision. (Show Details)Nov 3 2020, 12:12 AM
tlively accepted this revision.Nov 3 2020, 10:03 AM

Excellent, thanks! I'll land this.

This revision is now accepted and ready to land.Nov 3 2020, 10:03 AM
This revision was landed with ongoing or failed builds.Nov 3 2020, 10:46 AM
Closed by commit rG107c3a12d627: [WebAssembly] Implement ref.null (authored by wingo, committed by tlively). · Explain Why
This revision was automatically updated to reflect the committed changes.