llvm-project/llvm/test/Assembler/align-inst-load.ll

; RUN: not llvm-as %s -o /dev/null 2>/dev/null

define void @foo(i1* %p) {
  load i1, i1* %p, align 8589934592
  ret void
}
Define a maximum supported alignment value for load, store, and alloca instructions (constrained by their internal encoding), and add error checking for it. Fix an instcombine bug which generated huge alignment values (null is infinitely aligned). This fixes undefined behavior noticed by John Regehr. llvm-svn: 109643 2010-07-29 04:12:04 +08:00			`; RUN: not llvm-as %s -o /dev/null 2>/dev/null`

The maximal representable alignment in LLVM IR is 1GiB, not 512MiB 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 2021-08-26 16:51:28 +08:00			`define void @foo(i1* %p) {`
Reland [IR] Increase max alignment to 4GB Currently the max alignment representable is 1GB, see D108661. Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are clear which can be used for some optimizations, e.g. https://crbug.com/1016945. This uses an extra bit in instructions that carry an alignment. We can store 15 bits of "free" information, and with this change some instructions (e.g. AtomicCmpXchgInst) use 14 bits. We can increase the max alignment representable above 4GB (up to 2^62) since we're only using 33 of the 64 values, but I've just limited it to 4GB for now. The one place we have to update the bitcode format is for the alloca instruction. It stores its alignment into 5 bits of a 32 bit bitfield. I've added another field which is 8 bits and should be future proof for a while. For backward compatibility, we check if the old field has a value and use that, otherwise use the new field. Updating clang's max allowed alignment will come in a future patch. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D110451 2021-09-25 06:54:17 +08:00			`load i1, i1* %p, align 8589934592`
Define a maximum supported alignment value for load, store, and alloca instructions (constrained by their internal encoding), and add error checking for it. Fix an instcombine bug which generated huge alignment values (null is infinitely aligned). This fixes undefined behavior noticed by John Regehr. llvm-svn: 109643 2010-07-29 04:12:04 +08:00			`ret void`
			`}`