[all-commits] [llvm/llvm-project] 564d85: The maximal representable alignment in LLVM IR is ...

[Roman Lebedev via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 564d85e090afdaac6475d43708d77a7fa0cf5301
      https://github.com/llvm/llvm-project/commit/564d85e090afdaac6475d43708d77a7fa0cf5301
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2021-08-26 (Thu, 26 Aug 2021)

  Changed paths:
    M clang/include/clang/Sema/Sema.h
    M clang/test/CXX/drs/dr6xx.cpp
    M clang/test/CodeGen/builtin-assume-aligned.c
    M clang/test/CodeGen/catch-alignment-assumption-attribute-align_value-on-paramvar.cpp
    M clang/test/CodeGen/catch-alignment-assumption-builtin_assume_aligned-three-params-variable.cpp
    M clang/test/CodeGen/catch-alignment-assumption-builtin_assume_aligned-three-params.cpp
    M clang/test/CodeGen/catch-alignment-assumption-builtin_assume_aligned-two-params.cpp
    M clang/test/CodeGen/catch-alignment-assumption-openmp.cpp
    M clang/test/Sema/alloc-align-attr.c
    M clang/test/Sema/attr-aligned.c
    M clang/test/Sema/builtin-assume-aligned.c
    M clang/test/SemaCXX/alloc-align-attr.cpp
    M llvm/include/llvm/IR/Instruction.h
    M llvm/include/llvm/IR/Value.h
    M llvm/test/Assembler/align-inst-alloca.ll
    M llvm/test/Assembler/align-inst-load.ll
    M llvm/test/Assembler/align-inst-store.ll
    M llvm/test/Assembler/align-inst.ll
    M llvm/test/Bitcode/inalloca.ll
    A llvm/test/CodeGen/MIR/X86/load-with-1gb-alignment.mir
    M llvm/test/Transforms/Attributor/ArgumentPromotion/live_called_from_dead.ll
    M llvm/test/Transforms/Attributor/ArgumentPromotion/live_called_from_dead_2.ll
    M llvm/test/Transforms/Attributor/IPConstantProp/PR26044.ll
    M llvm/test/Transforms/Attributor/IPConstantProp/pthreads.ll
    M llvm/test/Transforms/Attributor/callbacks.ll
    M llvm/test/Transforms/Attributor/liveness.ll
    M llvm/test/Transforms/Attributor/memory_locations.ll
    M llvm/test/Transforms/Attributor/noalias.ll
    M llvm/test/Transforms/Attributor/nocapture-1.ll
    M llvm/test/Transforms/Attributor/noundef.ll
    M llvm/test/Transforms/Attributor/undefined_behavior.ll
    M llvm/test/Transforms/Attributor/value-simplify.ll
    M llvm/test/Transforms/GVN/PRE/2017-06-28-pre-load-dbgloc.ll
    M llvm/test/Transforms/InstCombine/atomic.ll
    M llvm/test/Transforms/InstCombine/getelementptr.ll
    M llvm/test/Transforms/InstCombine/load.ll
    M llvm/test/Transforms/InstCombine/mempcpy.ll
    M llvm/test/Transforms/InstCombine/pr44245.ll
    M llvm/test/Transforms/InstCombine/store.ll
    M llvm/test/Transforms/OpenMP/parallel_level_fold.ll
    M llvm/test/Verifier/align-md.ll
    M llvm/unittests/IR/ValueTest.cpp

  Log Message:
  -----------
  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