[llvm-dev] Adding a new polymorphic type for the WebAssembly backend

Paulo Matos via llvm-dev llvm-dev at lists.llvm.org
Wed Nov 10 00:25:39 PST 2021


Hi,

In the WebAssembly backend we are trying to add support for intrinsics
that deal with reference types (externref and funcref): opaque
host-managed values.

These are represented as pointers to address spaces 10 and 20. You can
see the address space definitions here:
https://github.com/llvm/llvm-project/blob/0cada82f0a30e5ae22dce66b58604ab9b47a3897/llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.h#L33

In the same file you'll also see definitions for type predicates
isFuncrefType and isExternrefType.

MVTs funcref and externref exist but they don't have a new type
associated with them and we want to avoid adding these. So an externref
is represented aa pointer to an opaque struct in address space 10 and a
funcref is a pointer to an i8 in address space 20 that if called, is
bitcast to the correct function type. 

Part of the work in D111227 (https://reviews.llvm.org/D111227) has been
to define a new polymorphic type llvm_anyref_ty that recognizes both
externref and funcref types.

In order to add this polymorphic type, we need to add an ArgKind enum
AK_AnyRef for it in Intrinsics.h. Trouble comes when in Function.cpp
we need to add a predicate for the ArgKind (AK_AnyRef). The predicate
recognizing this is currently in WebAssemblyUtilities.h and moving them
to Type.h or wrapping them there would mean a target dependent include
(to access the address space definitions) or target dependent
definitions in Type.h (if we move the address space enum and
definitions there).

There seems to be some precendence in target dependent types in there,
like X86_MMXTy and X86_AMXTy. However, things have been shuffled around
such that no includes to target dependent files exist. I wonder if it
would be acceptable to include predicated to Wasm reference types along
with the address space definitions there and if not, what alternatives
there are to this?

Thanks!

-- 
Paulo Matos


More information about the llvm-dev mailing list