llvm-mirror/test/Verifier/token3.ll

; RUN: not llvm-as %s -o /dev/null 2>&1 | FileCheck %s

define void @f(token %A, token %B) {
entry:
  alloca token
; CHECK: invalid type for alloca
  ret void
}
[IR] Add token types This introduces the basic functionality to support "token types". The motivation stems from the need to perform operations on a Value whose provenance cannot be obscured. There are several applications for such a type but my immediate motivation stems from WinEH. Our personality routine enforces a single-entry - single-exit regime for cleanups. After several rounds of optimizations, we may be left with a terminator whose "cleanup-entry block" is not entirely clear because control flow has merged two cleanups together. We have experimented with using labels as operands inside of instructions which are not terminators to indicate where we came from but found that LLVM does not expect such exotic uses of BasicBlocks. Instead, we can use this new type to clearly associate the "entry point" and "exit point" of our cleanup. This is done by having the cleanuppad yield a Token and consuming it at the cleanupret. The token type makes it impossible to obscure or otherwise hide the Value, making it trivial to track the relationship between the two points. What is the burden to the optimizer? Well, it turns out we have already paid down this cost by accepting that there are certain calls that we are not permitted to duplicate, optimizations have to watch out for such instructions anyway. There are additional places in the optimizer that we will probably have to update but early examination has given me the impression that this will not be heroic. Differential Revision: http://reviews.llvm.org/D11861 llvm-svn: 245029 2015-08-14 07:09:07 +02:00			`; RUN: not llvm-as %s -o /dev/null 2>&1 \| FileCheck %s`

			`define void @f(token %A, token %B) {`
			`entry:`
			`alloca token`
			`; CHECK: invalid type for alloca`
			`ret void`
			`}`