6f371149c1
Currently, the IR parser requires that %n style numbered values are consecutive. This means that the IR becomes invalid as soon as you remove an instruction, argument or block. This makes it very annoying to modify IR without running it through instnamer first. I don't think there is any good reason to impose this requirement. This PR relaxes it to allow value IDs to be non-consecutive, but it still keeps the requirement that they're increasing (i.e. you can't skip a value number and then assign it later). This only implements support for skipping numbers for local values. We should extend this to global values in the future as well.
23 lines
1001 B
LLVM
23 lines
1001 B
LLVM
; RUN: not llvm-as %s -o /dev/null 2>&1 | FileCheck %s
|
|
; RUN: llvm-as %s -data-layout=P42 -o - | llvm-dis - -o - | FileCheck %s -check-prefix PROGAS42
|
|
|
|
; Check that numbered variables in a nonzero program address space 200 can be used in a call instruction
|
|
|
|
define i8 @test_unnamed(ptr, ptr addrspace(42) %1) {
|
|
; Calls with explicit address spaces are fine:
|
|
call addrspace(0) i8 %0(i32 0)
|
|
call addrspace(42) i8 %1(i32 0)
|
|
; this call is fine if the program address space is 42
|
|
call i8 %1(i32 0)
|
|
; CHECK: call-nonzero-program-addrspace-2.ll:[[@LINE-1]]:11: error: '%1' defined with type 'ptr addrspace(42)' but expected 'ptr'
|
|
ret i8 0
|
|
}
|
|
|
|
; PROGAS42: target datalayout = "P42"
|
|
; PROGAS42: define i8 @test_unnamed(ptr %0, ptr addrspace(42) %1) addrspace(42) {
|
|
; PROGAS42-NEXT: %3 = call addrspace(0) i8 %0(i32 0)
|
|
; PROGAS42-NEXT: %4 = call addrspace(42) i8 %1(i32 0)
|
|
; PROGAS42-NEXT: %5 = call addrspace(42) i8 %1(i32 0)
|
|
; PROGAS42-NEXT: ret i8 0
|
|
; PROGAS42-NEXT: }
|