[llvm-dev] does clang plan to match gcc's pointer-to-vector-element feature?
Qiu Chaofan via llvm-dev
llvm-dev at lists.llvm.org
Wed Nov 6 21:16:03 PST 2019
In LLVM official docs, there're some parts mentioning this:
> This hasn’t always been forcefully disallowed, though it’s not recommended. It leads to awkward special cases in the optimizers, and fundamental inconsistency in the IR. In the future, it will probably be outright disallowed.
> LLVM IR has first class vector types. In LLVM IR, the zero’th element of a vector resides at the lowest memory address. The optimizer relies on this property in certain areas, for example when concatenating vectors together. The intention is for arrays and vectors to have identical memory layouts - `[4 x i8]` and `<4 x i8>` should be represented the same in memory. Without this property there would be many special cases that the optimizer would have to cleverly handle.
It is, not recommended but not wrong, I think.
Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> 于2019年11月4日周一 上午11:46写道：
> Two questions:
> (1) is it planned for GEP to work on vector elements?
> (2) do vectors have a well-defined in-memory layout?
> I see that  says:
> > This hasn’t always been forcefully disallowed, though it’s not
> recommended. It leads to awkward special cases in the optimizers, and
> fundamental inconsistency in the IR. In the future, it will probably be
> outright disallowed.
> However please take a look at the godbolt link. If clang wants to match
> feature parity of gcc, then (1) or (2) must be utilized.
> What's the plan? I'm trying to implement this feature in Zig but it
> seems that LLVM IR does not provide enough guarantees for this feature
> to be sound.
> Thanks for the advice,
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
More information about the llvm-dev