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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071206/b4de127f/attachment.html>
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 > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071207/13b7a111/attachment.html>
Will do. I'll package up a small repro and file it. ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] 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 LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071207/9b373984/attachment.html>
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.