llvm-mirror/test/Assembler/datalayout-alloca-addrspace-mismatch-2.ll

; RUN: not llvm-as < %s 2>&1 | FileCheck %s

target datalayout = "A1"

; CHECK: Allocation instruction pointer not in the stack address space!
; CHECK-NEXT:  %alloca_scalar_no_align = alloca i32, align 4, addrspace(2), !foo !0

define void @use_alloca() {
  %alloca_scalar_no_align = alloca i32, align 4, addrspace(2), !foo !0
  ret void
}

!0 = !{}
Allow DataLayout to specify addrspace for allocas. LLVM makes several assumptions about address space 0. However, alloca is presently constrained to always return this address space. There's no real way to avoid using alloca, so without this there is no way to opt out of these assumptions. The problematic assumptions include: - That the pointer size used for the stack is the same size as the code size pointer, which is also the maximum sized pointer. - That 0 is an invalid, non-dereferencable pointer value. These are problems for AMDGPU because alloca is used to implement the private address space, which uses a 32-bit index as the pointer value. Other pointers are 64-bit and behave more like LLVM's notion of generic address space. By changing the address space used for allocas, we can change our generic pointer type to be LLVM's generic pointer type which does have similar properties. llvm-svn: 299888 2017-04-10 22:27:50 +00:00			`; RUN: not llvm-as < %s 2>&1 \| FileCheck %s`

			`target datalayout = "A1"`

LLParser: add an argument for overriding data layout and do not check alloca addr space Sometimes users do not specify data layout in LLVM assembly and let llc set the data layout by target triple after loading the LLVM assembly. Currently the parser checks alloca address space no matter whether the LLVM assembly contains data layout definition, which causes false alarm since the default data layout does not contain the correct alloca address space. The parser also calls verifier to check debug info and updating invalid debug info. Currently there is no way to let the verifier to check debug info only. If the verifier finds non-debug-info issues the parser will fail. For llc, the fix is to remove the check of alloca addr space in the parser and disable updating debug info, and defer the updating of debug info and verification to be after setting data layout of the IR by target. For other llvm tools, since they do not override data layout by target but instead can override data layout by a command line option, an argument for overriding data layout is added to the parser. In cases where data layout overriding is necessary for the parser, the data layout can be provided by command line. Differential Revision: https://reviews.llvm.org/D41832 llvm-svn: 323826 2018-01-30 22:32:39 +00:00			`; CHECK: Allocation instruction pointer not in the stack address space!`
			`; CHECK-NEXT: %alloca_scalar_no_align = alloca i32, align 4, addrspace(2), !foo !0`

Allow DataLayout to specify addrspace for allocas. LLVM makes several assumptions about address space 0. However, alloca is presently constrained to always return this address space. There's no real way to avoid using alloca, so without this there is no way to opt out of these assumptions. The problematic assumptions include: - That the pointer size used for the stack is the same size as the code size pointer, which is also the maximum sized pointer. - That 0 is an invalid, non-dereferencable pointer value. These are problems for AMDGPU because alloca is used to implement the private address space, which uses a 32-bit index as the pointer value. Other pointers are 64-bit and behave more like LLVM's notion of generic address space. By changing the address space used for allocas, we can change our generic pointer type to be LLVM's generic pointer type which does have similar properties. llvm-svn: 299888 2017-04-10 22:27:50 +00:00			`define void @use_alloca() {`
			`%alloca_scalar_no_align = alloca i32, align 4, addrspace(2), !foo !0`
			`ret void`
			`}`

			`!0 = !{}`