[llvm-commits] PATCH: remove VICmp and VFCmp.

[Chris Lattner]

On Jul 9, 2009, at 11:07 AM, Duncan Sands wrote:
> Hi David,
> I haven't been tracking this, so can someone explain what the  
> "vectors of
>>>> i1 problem" is?  Is it a problem of how to generate code on  
>>>> architectures
>>>> that don't have a mask concept?
>>> how is <8 x i1> stored in memory?  8 bits packed into a byte, or  
>>> like an
>>> array [8 x i1], which on most machines is stored as 8 bytes?  I  
>>> think it
>>> is clear that it should be stored the same as an array would be.
>>
>> That's not at all clear to me.  A vector mask is a bit-packed  
>> vector of
>> i1 and we're going to need some way of representing that in the LLVM
>> IR (Instructions, SDNodes and MachineInstructions).
>
> actual usage is of course a consideration.  However if you want all
> vectors to be bit packed then this means that vectors of x86 long
> double will be bit-packed too.  GCC supports vectors of long double
> and it doesn't seem to bit-pack them...  Of course such GCC vectors
> can be thunked into non-vectors when converting to LLVM.  Bitpacking
> also makes codegen more complicated.

Right, I don't think it's worth it.  It's not just <4 x i1> that we're  
talking about, it's also stuff like <17 x i37>, which should work, but  
no-one would expect to be efficient. :)

>>> bits packed into an i8.  In general, LLVM thinks that <N x Ty>  
>>> occupies
>>> N * size_of_Ty_in_bits bits.  This causes all kinds of problems.
>>> Consider for example a vector of two x86 long double.  These are 10
>>> bytes long, the vector is thus 20 bytes long.  This means that the
>>> second long double will be stored 10 bytes offset from the start.   
>>> Thus
>>> it will not be aligned.  Etc etc.
>>
>> So won't legalize fix that when it realizes a vector of long double  
>> is
>> an illegal type on x86?
>
> I guess the second long double could be stored via a bunch of  
> (aligned)
> integer operations, but that would be pretty sucky.

vector of long double *is* illegal on x86, because the hardware  
doesn't support it.  The question is "what does legalize do with the  
load/store operations" when it legalizes them.

> At least given the
>> current semantics of vector.  If we change the semantics then of  
>> course
>> all bets are off.  But we definitely need some way of expressing  
>> bit-packed
>> information that naturally operates as a vector.
>
> So the processor really operates with such bit-packed vectors,  
> producing
> them as results for comparisons?

If a processor has that, it can use intrinsics.  It's not as if two  
chips that support <4 x i1> natively in hardware would agree on a  
memory format anyway :)

> Anyway, some kind of definitive decision needs to be made about how
> vectors are to be represented in memory.  Presumably Chris should
> pronounce on this from on-high :)

They should have the same memory layout as arrays.

-Chris