[llvm-dev] bitcast <8 x i1> to i8 - dependence on endianness?

[Markus Lavin via llvm-dev]

> Apparently this is different to the rest of llvm, which assumes the opposite
> for non-byte sized vectors? That is surprising, we even have some
> instructions under MVE for storing predicates which under big endian
> assume the low lane is in the low bits. I would not be surprised if this was
> causing problems somewhere under big endian though, it does not get
> nearly as much use as little endian.

I don't know but it seems unlikely that this pass can work correctly for general big-endian considering that

- LLVM IR has first class vector types. In LLVM IR, the zero'th element of a vector resides at the lowest memory address. (from https://llvm.org/docs/BigEndianNEON.html)
 - The result of bitcast <8 x i1> to i8 experiments in my previous post.

> > @markus: Could you help out locating the functions that we think is wrong
> in those tests? Maybe even upload your fixes in
> ScalarizeMaskedMemIntrin.cpp to Phabricator to show the differences both
> to the LLVM code and the new codegen for those test cases?
> 
> Yeah, If you can upload a phabricator review for the changes in the
> expansion of masked intrinsics, I can take a look into the MVE codegen and
> see if I can get it to store in the opposite order sensibly. I have not looked at
> what that would take yet, but I'm hoping it's not too difficult.

The fix I tried is as follows https://reviews.llvm.org/D94765 but it results in the three failed mve-masked-*.ll tests mentioned.

Thanks,
Markus