[LLVM IR] Possible compiler bug: <N x i1> vector instructions ordering causing different results

I have been using LLVM as a backend for my compiler (I’m not using the LLVM libraries but my own to generate the necessary IR for numerous reasons). At the moment, I am implementing vector operations. Comparisons of vectors emit vectors of booleans <N x i1> and these are causing me problems.

To access vector elements, I have been using extractelement and insertelement however, I am getting some weird behaviour when I execute these instructions in a different orders. The code examples below have the same instructions and should be logically the same. Version 1 outputs BAAwhile Version 2 outputs BAB. Version 2 is the logically correct version but I cannot figure out why version 1 outputs the wrong version but has the exact same instructions, just in a different order.

I’m suspecting this may be a compiler bug rather than a code error. It may be due to the way vectors structured. I could not find any documentation on what the size of a vector is but it seems that vector elements get packed. <N x iM> size == (N*M+7)/8 bytes. This also suggests why the FAQ suggests not to use getelementptr on vectors as the elements may not be byte aligned.

As a workaround, is there a way to make sure a boolean vector isn’t packed where each element takes up a byte, or convert a vector of booleans to either a vector of i8, or extra instructions to prevent this from happening?

Regards,

Bill

Hi Bill,

I highly recommend that you use only vectors of elements which have a size which is a whole number of bytes. There are known issues with how we handle the more-general cases, see:

https://llvm.org/bugs/show_bug.cgi?id=1784
https://llvm.org/bugs/show_bug.cgi?id=22603
https://llvm.org/bugs/show_bug.cgi?id=27600

In short, different parts of the compiler disagree on whether <8 x i1> is one or eight bytes long, and some parts do nonsensical things altogether. There are a limited subset of cases where the current infrastructure works well (mostly for handling vectors of i1 for vectorized comparisons), but if you stray too far you’ll run into problems. That having been said, we would like to fix these things, and so if you find problems, please do file bug reports about them.

-Hal