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

[Andy Wingo via Phabricator via llvm-commits]

wingo added a comment.

Thanks for your time, arsenm.

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

> I did envision this being useful, however there are a few points of concern:
>
> 1. This does remove the safety check for the common case of creating an alloca without checking the datalayout's default alloca address space

Yeah I can see why you might want this.  If we want to keep the footgun-protection, one way would be to allow a target to explicitly opt out of the alloca address-space check.  Something like:

  target datalayout = "A1*"

to indicate that this target uses AS 1 by default for alloca, but that it can use others.  Then we'd adapt the Verifier check to see if this datalayout allows alloca in other address spaces.  WDYT?

> 1. How is this going to be represented in codegen? In SelectionDAG the pointer type is immediately discarded and frame indexes don't have a tracked address space

We override `TargetLowering::getPointerTy(DataLayout&, unsigned AS)` to return a different MVT for these address spaces.  We then have custom lowering for ISD::LOAD / ISD::STORE for those special MVTs.

Just for context, on the wasm target, each function has two stacks frame: 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.  SSAV 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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101045