Regression on <4 x i1>?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Regression on <4 x i1>?

Chuck Rose III

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.

 

 

 


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Regression on <4 x i1>?

Evan Cheng-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

On Dec 6, 2007, at 5:06 PM, Chuck Rose III wrote:

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.
 
 
 
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Regression on <4 x i1>?

Chuck Rose III

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

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Evan Cheng
Sent: Friday, December 07, 2007 1:23 PM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] Regression on <4 x i1>?

 

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

 

On Dec 6, 2007, at 5:06 PM, Chuck Rose III wrote:



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.

 

 

 

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

 


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Regression on <4 x i1>?

Duncan Sands
In reply to this post by Evan Cheng-2
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.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev