search for: getalignmentinfo

...> TargetData or there's something else wrong with TargetData? > > Did you walk through it in the debugger? Yes. It appears that TargetData doesn't have logic to match the case of vector types smaller than the smallest defined ABI vector type. It's asserting in TargetData::getAlignmentInfo: assert(BestMatchIdx != -1 && "Didn't find alignment info for this datatype!"); I don't think it has enough information to be able to determine whether or not it's being asked for the alignment of a smaller vector type that could be mapped onto a non-vector typ...

...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...

...s something else wrong with TargetData? > > > > Did you walk through it in the debugger? > > Yes. It appears that TargetData doesn't have logic to match the case > of vector types smaller than the smallest defined ABI vector type. > It's asserting in TargetData::getAlignmentInfo: > > assert(BestMatchIdx != -1 && "Didn't find alignment info for this > datatype!"); That makes sense. > > I don't think it has enough information to be able to determine > whether or not it's being asked for the alignment of a smaller vector...

...e 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...

...age using LLVM 2.5, i could see the error message on llc processing. > llvm-gcc -emit-llvm ./od.c -c -o ./od.bc -other-options... > llc -march=arm ./od.bc -f -o ./od.s llc: /home/jaykang10/HardDisk2/Projects/LLVM/src/llvm-2.5/lib/Target/TargetData.cpp:305: unsigned int llvm::TargetData::getAlignmentInfo(llvm::AlignTypeEnum, uint32_t, bool, const llvm::Type*) const: Assertion `AlignType == VECTOR_ALIGN && "Unknown alignment type!"' failed. The problem was that when i converted 'od' source code to llvm bitcode, long double type of 'od' source code was changed t...

On Mon, 22 May 2017, Dr. ERDI Gergo wrote: > Actually, tracking down the sequence of function calls, it turns out that '8' > is ultimately coming from the following call in DataLayout::getAlignment: > > getAlignmentInfo(AGGREGATE_ALIGN, 0, abi_or_pref, Ty); > > this seems to return 8 with the following datalayout string: > > e-S8:p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8 > > I think my problem is that 'a:8' probably doesn't mean what I think it should > mean. What is the di...

On Mon, 22 May 2017, Krzysztof Parzyszek via llvm-dev wrote: > Probably from LargeArrayMinWidth/LargeArrayAlign settings in Targets.cpp (in > clang). Wait what? In clang? But my input is already LLVM IR. MF->getDataLayout().getPrefTypeAlignment(Ty) must be basing its answer on either something in the IR file, or in the target implementation, but clang is not really in the picture.

...d see the error message on llc processing. > > > llvm-gcc -emit-llvm ./od.c -c -o ./od.bc -other-options... > > llc -march=arm ./od.bc -f -o ./od.s > llc: /home/jaykang10/HardDisk2/Projects/LLVM/src/llvm-2.5/lib/Target/ > TargetData.cpp:305: unsigned int llvm::TargetData::getAlignmentInfo > (llvm::AlignTypeEnum, uint32_t, bool, const llvm::Type*) const: > Assertion `AlignType == VECTOR_ALIGN && "Unknown alignment type!"' > failed. > > The problem was that > when i converted 'od' source code to llvm bitcode, long double type >...

...could see the error message on llc processing. > > llvm-gcc -emit-llvm ./od.c -c -o ./od.bc /-other-options.../ > > llc -march=arm ./od.bc -f -o ./od.s > llc: > /home/jaykang10/HardDisk2/Projects/LLVM/src/llvm-2.5/lib/Target/TargetData.cpp:305: > unsigned int llvm::TargetData::getAlignmentInfo(llvm::AlignTypeEnum, > uint32_t, bool, const llvm::Type*) const: Assertion `AlignType == > VECTOR_ALIGN && "Unknown alignment type!"' failed. > The problem was that > when i converted 'od' source code to llvm bitcode, long double type of > 'od' s...

...age using LLVM 2.5, i could see the error message on llc processing. > llvm-gcc -emit-llvm ./od.c -c -o ./od.bc -other-options... > llc -march=arm ./od.bc -f -o ./od.s llc: /home/jaykang10/HardDisk2/Projects/LLVM/src/llvm-2.5/lib/Target/TargetData.cpp:305: unsigned int llvm::TargetData::getAlignmentInfo(llvm::AlignTypeEnum, uint32_t, bool, const llvm::Type*) const: Assertion `AlignType == VECTOR_ALIGN && "Unknown alignment type!"' failed. The problem was that when i converted 'od' source code to llvm bitcode, long double type of 'od' source code was changed t...

...processing. >> >> > llvm-gcc -emit-llvm ./od.c -c -o ./od.bc -other-options... >> > llc -march=arm ./od.bc -f -o ./od.s >> llc: /home/jaykang10/HardDisk2/Projects/LLVM/src/llvm-2.5/lib/ >> Target/TargetData.cpp:305: unsigned int >> llvm::TargetData::getAlignmentInfo(llvm::AlignTypeEnum, uint32_t, >> bool, const llvm::Type*) const: Assertion `AlignType == >> VECTOR_ALIGN && "Unknown alignment type!"' failed. >> >> The problem was that >> when i converted 'od' source code to llvm bitcode, long doubl...

...lvm.org>: > >> On Mon, 22 May 2017, Dr. ERDI Gergo wrote: >> >> Actually, tracking down the sequence of function calls, it turns out that >>> '8' is ultimately coming from the following call in >>> DataLayout::getAlignment: >>> >>> getAlignmentInfo(AGGREGATE_ALIGN, 0, abi_or_pref, Ty); >>> >>> this seems to return 8 with the following datalayout string: >>> >>> e-S8:p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8 >>> >>> I think my problem is that 'a:8' probably doesn't mean w...

...gin(), + e = UnTy->element_end(); i != e; ++i) { + Size = std::max(Size, getTypeSizeInBits(*i)); + } + return Size; + } case Type::IntegerTyID: return cast<IntegerType>(Ty)->getBitWidth(); case Type::VoidTyID: @@ -516,6 +525,17 @@ unsigned Align = getAlignmentInfo(AGGREGATE_ALIGN, 0, abi_or_pref, Ty); return std::max(Align, (unsigned)Layout->getAlignment()); } + case Type::UnionTyID: { + const UnionType *UnTy = cast<UnionType>(Ty); + unsigned Align = 1; + + // Unions need the maximum alignment of all their entries + for (UnionTy...

Hello, I noticed a bit of a gap in the current code for unions: a ConstantUnion cannot be written out to .ll. Hopefully I'm not stepping on Talin's toes by posting this, it's a fairly straightforward adaptation of the code for structs just above. Tim. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. --------------