does clang plan to match gcc's pointer-to-vector-element feature?

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 [1] 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.

[1]:
http://llvm.org/docs/GetElementPtr.html#can-gep-index-into-vector-elements

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,
Andrew

Hi,

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.

(The Often Misunderstood GEP Instruction — LLVM 18.0.0git documentation )

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.

(Using ARM NEON instructions in big endian mode — LLVM 18.0.0git documentation )

It is, not recommended but not wrong, I think.

Regards,
Chaofan

Andrew Kelley via llvm-dev <llvm-dev@lists.llvm.org> 于2019年11月4日周一 上午11:46写道: