llvm dev - May 2010 - [LLVMdev] SplitVecRes_LOAD

I was going through the function DAGTypeLegalizer::SplitVecRes_LOAD in
LegalizeVectorTypes.cpp. I noticed that it is using getSizeInBits()/8
to compute IncrementSize, which is the offset for the load of second
half of the vector. I have a situation where the frontend is producing
load for a <2 x i1> type, and the architecture has i1 registers (but
not v2i1 registers). The store size of i1 is 8 bits (the size returned
by getStoreSizeInBits()). When SplitVecRes_LOAD is called, because it
is using getSizeInBits()/8, the offset for the second half is zero, so
it ends up using the same i1 value for both the halves. Is this a bug,
or am I missing something?

Thanks,
Manjunath

On May 4, 2010, at 5:33 PM, Manjunath Kudlur wrote:
> I was going through the function DAGTypeLegalizer::SplitVecRes_LOAD in
> LegalizeVectorTypes.cpp. I noticed that it is using getSizeInBits()/8
> to compute IncrementSize, which is the offset for the load of second
> half of the vector. I have a situation where the frontend is producing
> load for a <2 x i1> type, and the architecture has i1 registers (but
> not v2i1 registers). The store size of i1 is 8 bits (the size returned
> by getStoreSizeInBits()). When SplitVecRes_LOAD is called, because it
> is using getSizeInBits()/8, the offset for the second half is zero, so
> it ends up using the same i1 value for both the halves. Is this a bug,
> or am I missing something?
It's a bug. LLVM doesn't really support vectors of
non-byte-divisible elements in memory very well.

Dan

Hi Manjunath, see http://llvm.org/bugs/show_bug.cgi?id=1784