Regression on <4 x i1>?

Project Infrastructure LLVM Dev List Archives
1

Hola LLVMers,

One of the corner-case features of the Hydra language I work on are Boolean vectors of length 2, 3, or 4 which I’ve been representing as either <2 x i1> or <4 x i1>. I picked up the latest LLVM about a week back and since then I’ve been unable to compile things using this construct. It asserts in TargetData::getAlignmentInfo since it doesn’t have alignment data for these types. This is on x86 JIT.

As an experiment, I added alignments for these data type, so that it would get past the getAlignmentInfo check, but then it doesn’t know how to handle things data type further down the register allocation pipeline.

Is anyone else seeing problems with these types on x86? Do you have some pointers on how to look into fixing this? I don’t want to stumble around blindly and the final code generation is not a part of the system I’m familiar with.

Thanks,

Chuck.

2

Duncan, could this be related to your recent work?

Chuck, this is unlikely to be a x86 specific problem. Please file a bug. Thanks!

Evan

3

Will do. I'll package up a small repro and file it.

4

Hi Evan,

Duncan, could this be related to your recent work?

it could well be. That said, vectors with gaps in them are
broken in many ways. This goes for vectors of apints like i1
as well as vectors of 80-bit x86 long double.

Here's an extract of an email I sent to Dale Johannesen:

Hi Dale, I just noticed that vectors of x86_fp80 are likely
to cause lots of trouble. Plenty of vector logic seems to
assume that the vector is densely packed, with no gaps due
to alignment. For example, the method that returns the size of a
vector in bits (getBitWidth) returns the primitive size in bits of
the element times the number of elements. In other words
it won't take into account the alignment padding of an x86_fp80.
This is nasty because to get the alignment you need TargetData,
so all of a sudden you need TargetData to compute the bitdwidth of a
vector.

Also, I was looking at scalar replacement of agregates, and
the logic there looks pretty dubious for vectors of x86_fp80.
For example, it thinks it is OK to treat vectors of x86_fp80
and vectors of i80 the same:

...

How long is a <4 x i1>? It's not 4 bits long (which is what
getBitWidth says), it's 4 bytes long. I'm not sure this is
what Chuck wants...

Ciao,

Duncan.