<br /><br />16:49, 15 de enero de 2021, "Markus Lavin via llvm-dev" <llvm-dev@lists.llvm.org>:<br /><blockquote class="210e7a848e8fcb45wmi-quote"><blockquote class="210e7a848e8fcb45wmi-quote"> Apparently this is different to the rest of llvm, which assumes the opposite<br /> for non-byte sized vectors? That is surprising, we even have some<br /> instructions under MVE for storing predicates which under big endian<br /> assume the low lane is in the low bits. I would not be surprised if this was<br /> causing problems somewhere under big endian though, it does not get<br /> nearly as much use as little endian.<br /></blockquote><p><br />I don't know but it seems unlikely that this pass can work correctly for general big-endian considering that<br /><br />- LLVM IR has first class vector types. In LLVM IR, the zero'th element of a vector resides at the lowest memory address. (from <a href="https://llvm.org/docs/BigEndianNEON.html">https://llvm.org/docs/BigEndianNEON.html</a>)<br /> - The result of bitcast <8 x i1> to i8 experiments in my previous post.</p></blockquote>I don't necessarily trust that overly-wordy page on NEON, but ppc64le in bardardly C (AltiVec) is bit-Endian, but was switched to little-Endian in LLVM-IR so that LLVM-IR could be consistently little-Endian. I don't think there are any big-Endian vector representations (and I don't believe they are, for indeed "The books of the big-Endians have bee long forbidden."--_Lemur Gulliver's Travels to Several Remote Nations of the World_)<div><br /></div><div>I also have extensively used <i1 x 8> to i8 and similar bitcasts.</div><div><br /></div><div>Shawn Landden<br /><blockquote class="210e7a848e8fcb45wmi-quote"><p></p><blockquote class="210e7a848e8fcb45wmi-quote"> > @markus: Could you help out locating the functions that we think is wrong<br /> in those tests? Maybe even upload your fixes in<br /> ScalarizeMaskedMemIntrin.cpp to Phabricator to show the differences both<br /> to the LLVM code and the new codegen for those test cases?<br /> <br /> Yeah, If you can upload a phabricator review for the changes in the<br /> expansion of masked intrinsics, I can take a look into the MVE codegen and<br /> see if I can get it to store in the opposite order sensibly. I have not looked at<br /> what that would take yet, but I'm hoping it's not too difficult.<br /></blockquote><p><br />The fix I tried is as follows <a href="https://reviews.llvm.org/D94765">https://reviews.llvm.org/D94765</a> but it results in the three failed mve-masked-*.ll tests mentioned.<br /><br />Thanks,<br />Markus<br />_______________________________________________<br />LLVM Developers mailing list<br /><a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br /><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br /></p></blockquote><br /><br />-- <br />Shawn Landden</div>