llvm-project/llvm/test/Assembler/invalid-datalayout-alloca-a...

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

target datalayout = "A16777216"
; CHECK: Invalid address space, must be a 24-bit integer
Revert "Revert "Reland "[Support] make report_fatal_error `abort` instead of `exit`""" This reverts commit 80a34ae31125aa46dcad47162ba45b152aed968d with fixes. Previously, since bots turning on EXPENSIVE_CHECKS are essentially turning on MachineVerifierPass by default on X86 and the fact that inline-asm-avx-v-constraint-32bit.ll and inline-asm-avx512vl-v-constraint-32bit.ll are not expected to generate functioning machine code, this would go down to `report_fatal_error` in MachineVerifierPass. Here passing `-verify-machineinstrs=0` to make the intent explicit. 2020-02-12 15:01:35 +08:00			`; RUN: not --crash llvm-as < %s 2>&1 \| FileCheck %s`
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-11 06:27:50 +08:00
			`target datalayout = "A16777216"`
Add default address space for functions to the data layout (1/3) Summary: This adds initial support for letting targets specify which address spaces their functions should reside in by default. If a function is created by a frontend, it will get the default address space specified in the DataLayout, unless the frontend explicitly uses a more general `llvm::Function` constructor. Function address spaces will become a part of the bitcode and textual IR forms, as we do not have access to a data layout whilst parsing LL. It will be possible to write IR that explicitly has `addrspace(n)` on a function. In this case, the function will reside in the specified space, ignoring the default in the DL. This is the first step towards placing functions into the correct address space for Harvard architectures. Full patchset * Add program address space to data layout D37052 * Require address space to be specified when creating functions D37054 * [clang] Require address space to be specified when creating functions D37057 Reviewers: pcc, arsenm, kparzysz, hfinkel, theraven Reviewed By: theraven Subscribers: arichardson, simoncook, rengolin, wdng, uabelho, bjope, asb, llvm-commits Differential Revision: https://reviews.llvm.org/D37052 llvm-svn: 325479 2018-02-19 17:56:22 +08:00			`; CHECK: Invalid address space, must be a 24-bit integer`