564d85e090
In LLVM IR, `AlignmentBitfieldElementT` is 5-bit wide But that means that the maximal alignment exponent is `(1<<5)-2`, which is `30`, not `29`. And indeed, alignment of `1073741824` roundtrips IR serialization-deserialization. While this doesn't seem all that important, this doubles the maximal supported alignment from 512MiB to 1GiB, and there's actually one noticeable use-case for that; On X86, the huge pages can have sizes of 2MiB and 1GiB (!). So while this doesn't add support for truly huge alignments, which i think we can easily-ish do if wanted, i think this adds zero-cost support for a not-trivially-dismissable case. I don't believe we need any upgrade infrastructure, and since we don't explicitly record the IR version, we don't need to bump one either. As @craig.topper speculates in D108661#2963519, this might be an artificial limit imposed by the original implementation of the `getAlignment()` functions. Differential Revision: https://reviews.llvm.org/D108661
20 lines
562 B
LLVM
20 lines
562 B
LLVM
; RUN: llvm-as < %s | llvm-dis | FileCheck %s
|
|
; RUN: verify-uselistorder < %s
|
|
|
|
; inalloca should roundtrip.
|
|
|
|
define void @foo(i32* inalloca(i32) %args) {
|
|
ret void
|
|
}
|
|
; CHECK-LABEL: define void @foo(i32* inalloca(i32) %args)
|
|
|
|
define void @bar() {
|
|
; Use the maximum alignment, since we stuff our bit with alignment.
|
|
%args = alloca inalloca i32, align 1073741824
|
|
call void @foo(i32* inalloca(i32) %args)
|
|
ret void
|
|
}
|
|
; CHECK-LABEL: define void @bar() {
|
|
; CHECK: %args = alloca inalloca i32, align 1073741824
|
|
; CHECK: call void @foo(i32* inalloca(i32) %args)
|