[PATCH] D138708: [SROA] Assert the AllocSize of i8 to be 1
Roman Lebedev via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Sat Nov 26 05:35:57 PST 2022
lebedev.ri added a comment.
In D138708#3951468 <https://reviews.llvm.org/D138708#3951468>, @jsilvanus wrote:
> I don't need support for overaligned `i8`s, it is fine for me to have LLVM require natural alignment on `i8`.
>
> But having explicit asserts maybe helps save some people's time in the future -- it certainly would have for me.
> Also, it explicitly documents the assumption underlying these GEPs.
>
> I'm not the sure the test brings additional value beyond motivating this change.
> There are probably many other places that can be broken by using such a data layout, and as long as
> there is no effort to make overaligned `i8`s work I see little value in documenting these.
>
> Thus, I'd propose to not commit the test and just add the assertions.
> But if you feel this issue should be discussed further, I'm fine to open a thread on that.
>
> For what it's worth, I ran into a similar, separate issue with incorrect GEP offsets during SROA with vectors of overaligned elements that I *do* intend to fix, because that should work.
Thank you for looking into this.
I do agree that this looks like a problem that needs to be improved.
There is a caveat here: while we should assert liberally, reachable assertions should be fixed in some way.
Indeed, the problem appears to happen the moment we create a datalayout with overaligned byte type.
So let's just detect that there, diagnose it as invalid, and refuse to create it?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D138708/new/
https://reviews.llvm.org/D138708
More information about the llvm-commits
mailing list