rjmccall added a reviewer: jfb. rjmccall added a comment. + JF, who knows something about Web Assembly, or can at least drag in the right people
In D108464#2959591 <https://reviews.llvm.org/D108464#2959591>, @wingo wrote: > In D108464#2957276 <https://reviews.llvm.org/D108464#2957276>, @wingo wrote: > >> Sooooo... besides the refactor, this is getting closer to where I'm going in >> https://lists.llvm.org/pipermail/cfe-dev/2021-July/068559.html, though still >> NFC. I think you can see where I would replace `getASTAllocaAddressSpace` >> with `getAllocaAddressSpace(QualType Ty)`, and possibly (depending on the >> source language) avoid casting the resulting alloca to `LangAS::Default`. >> WDYT, is this sort of thing OK? > > Taking this patch as perhaps a better generic discussion point, @rjmccall > graciously gave some general feedback on this approach (thank you!!!): > > In D108360#2957844 <https://reviews.llvm.org/D108360#2957844>, @rjmccall > wrote: > >> I'm not sure that I agree with your overall plan, though: >> >> - The WebAssembly operand stack is not a good match for an address space at >> the language level because it's not addressable at all. If you can't >> meaningfully have a pointer into the address space, then you don't really >> need this in the type system; it's more like a declaration modifier at best. >> - Allocating local variables on the operand stack ought to be a very >> straightforward analysis in the backend. There's not much optimization >> value in trying to do it in the frontend, and it's going to be problematic >> for things like coroutine lowering. >> - The security argument seems pretty weak, not because security isn't >> important but because this is not really an adequate basis for getting the >> tamper-proof guarantee you want. For example, LLVM passes can and do >> introduce its own allocas and store scalars into them sometimes. Really you >> need some sort of "tamper-proof" *type* which the compiler can make an >> end-to-end guarantee of non-tamper-ability for the values of, and while >> optimally this would be implemented by just keeping values on the operand >> stack, in the general case you will need to have some sort of strategy for >> keeping things in memory. > > Thanks for thinking about this! Indeed I started out with the goal of not > going deep into clang and if it's possible to avoid going too deeply, that > would be better for everyone involved. I am starting to think however that > it may be unavoidable for me at least. > > So, I am focusing on WebAssembly global and local variables; the WebAssembly > operand stack is an artifact of the IR-to-MC lowering and AFAICS doesn't have > any bearing on what clang does -- though perhaps I am misunderstanding what > you are getting at here. The issue is not to allocate locals on the operand > stack, but rather to allocate them as part of the "locals" of a WebAssembly > function > <https://webassembly.github.io/spec/core/syntax/modules.html#functions>. Cc > @tlively on the WebAssembly side. By "operand stack" I mean the innate, unaddressable stack that the WebAssembly VM maintains in order to make functions reentrant. I don't know what term the VM spec uses for it, but I believe "operand stack" is widely accepted terminology for the unaddressable stack when you've got this kind of dual-stack setup. And yes, VM "locals" would go there. > The main motivator is the ability to have "reference type" > <https://webassembly.github.io/spec/core/syntax/types.html#reference-types> > (`externref`/`funcref`) locals and globals > <https://webassembly.github.io/spec/core/syntax/modules.html#globals> at all. > Reference-typed values can't be stored to linear memory. They have no size > and no byte representation -- they are opaque values from the host. However, > WebAssembly locals and globals can define storage locations of type > `externref` or `funcref`. I see. I think you need to think carefully about the best way to represent values of these types in LLVM IR, because it probably cannot just be "treat them as a normal value, emit code a certain way that we know how to lower, and hope nothing goes wrong". It seems to me that you probably need a new IR type for it, since normal types aren't restricted from memory and tokens can't be used as parameters or return values. Hopefully, someone had a plan for this when they introduced that WebAssembly extension. > But, if we add a generic OpenCL-like address space attribute, that would > allow the user to declare some variables to be in alternate address spaces. > Then we can apply the ACLE SVE semantic restrictions to these values also, > and add on an additional restriction preventing address-of. That way users > get to make off-heap definitions, and if they misuse them, they get > comprehensible errors. LLVM IR and WebAssembly lowering is ready for these > alternate-address-space allocations. Again, I'm not sure you're getting anything at all from the address space side of this. The restrictions on these variables prevent any of the general address-space logic from applying. In a language sense, it's more like a storage class than an address space. > Regarding coroutine lowering, I can see how that can be challenging; would it > be reasonable to restrict continuations to not include saved off-heap locals, > for now? If there were such a local, it would be a compilation error. I suppose you would have to. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D108464/new/ https://reviews.llvm.org/D108464 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
