[PATCH] D101045: [IR][Verifier] Allow alloca outside alloca address space

[Andy Wingo via Phabricator via llvm-commits]

wingo added a comment.

In D101045#2711957 <https://reviews.llvm.org/D101045#2711957>, @arsenm wrote:

> It hadn't occurred to me to add a field to the datalayout purely for the verifier. That seems a bit strange, since it's not exactly a target property.

Yeah understood.  If we want some targets to have the check and some to not have the check, do you know of a better place to express this?  I thought the same place that the target's alloca address space is defined might not be unreasonable, but I am new here :)

In D101045#2711959 <https://reviews.llvm.org/D101045#2711959>, @arsenm wrote:

> In D101045#2711261 <https://reviews.llvm.org/D101045#2711261>, @wingo wrote:
>
>> Just for context, on the wasm target, each function has two stack frames: one managed by the webassembly run-time, populated by named locals, and not addressable; and one in memory managed as on conventional targets, sharing an address space with data and heap.  Clang produces IR where locals start life as alloca's as usual, and as usual the optimizer lifts most of them to SSA values in SROA.  SSA values end up lowering to the "named" part of the stack.  Those locals still left as allocas are put on linear memory.  This patch is motivated by ongoing work to add support for a new kind of value that can't be written to linear memory.  We are currently representing these values as opaque pointers in non-default address spaces, and have some special lowering hooks for these.  We also use some special address spaces to denote restricted pointers to these values.
>
> But are these still tracked in the MachineFrameInfo like a regular frame index?

They reach the MachineFrameInfo, but only ephemerally.  At the beginning of isel, the static alloca's get collected and the MachineFrameInfo populated with abstract objects and frame indexes.  Then when isel sees a load / store to these objects, the first load/store of the alloca causes it to be lifted out from the MachineFrameInfo and instead allocates it on the target-specific stack (as a WebAssembly local), and the object in the MachineFrameInfo is marked dead.  Loads and stores to these objects lower to accesses to the parallel stack instead of to objects in MachineFrameInfo.

Obviously this doesn't allow for by-reference access to these allocations.  This is OK for the WebAssembly target because these opaque types have source-level restrictions similar to the ones in place for ARM's SVE values -- see the ARM C Language Extensions (ACLE), §3.2.1 https://developer.arm.com/documentation/100987/0000.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101045/new/

https://reviews.llvm.org/D101045