[PATCH] D78810: [InstCombine] Check max alignment before adding attr on aligned_alloc
Roman Lebedev via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Apr 24 10:48:41 PDT 2020
lebedev.ri added a comment.
In D78810#2002021 <https://reviews.llvm.org/D78810#2002021>, @bondhugula wrote:
> In D78810#2001925 <https://reviews.llvm.org/D78810#2001925>, @lebedev.ri wrote:
>
> > Thank you for looking into this.
> > This should instead clamp to the maximal alignment. (the 'is power of 2' check should remain)
>
>
> Clamping would be incorrect here since the allocation risks not providing the desired alignment
> if it gets promoted to alloca.
Ah, interesting point, i have not considered it.
But then we already have that problem in other places,
at least `clang/lib/CodeGen/CGCall.cpp`, `AbstractAssumeAlignedAttrEmitter`.
> aligned_alloc doesn't appear to have an upper bound on ailgnment
> (any power of 2 size_t value is fine I think),
> while the 1 << 29 limit is for LLVM's alloca among others.
> I think the right/better fix for this could be to just add the attribute to aligned_alloc
> as long as it's a power of two, but not promote to alloca when it's larger than 1 << 29.
I'm not sure what you mean. Clearly, as per this patch, that is what we do now,
and it fails because there's an artificial (and bogus, too low) upper limit.
> But then I'm not sure if that would cause other undesired behavior in LLVM
> with an alignment attribute more than 1 << 29.
> If it did, then not adding the attribute at all for larger
> than MaximumAlignment appears to be the safe/right thing.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D78810/new/
https://reviews.llvm.org/D78810
More information about the llvm-commits
mailing list