search for: vector_align

...-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 to x86_fp80 type in llvm bitcode and then llc on ARM target was not support x86_fp80 type. I think t...

...eOffset(), ST->isVolatile(), OrigAlign); } Uhh...this doesn't seem legal to me. How can we just willy-nilly create a store with a greater alignment? In this case Align is 8 and OrigAlign is 16 because SVT.getTypeForMVT() is Type::VectorTyID (<2 x i64>) which has an ABI type of VECTOR_ALIGN. Hmm...why is the ABI alignment for VectorTyID 16? The ABI certainly doesn't guarantee it. It only guarantees it for __int128, __float128 and __m128. Lots of other types can map to <2 x i64>. Any opinions on this? -Dave

...... > > 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 to x86_fp80 type in llvm bitcode and > then llc on ARM target was no...

....../ > > 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 to x86_fp80 type in llvm bitcode and then > llc on ARM target was not support x86_fp...

...-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 to x86_fp80 type in llvm bitcode and then llc on ARM target was not support x86_fp80 type. I think t...

...m ./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 to x86_fp80 type in llvm bitcode >> and then llc on ARM...

...gAlign); > } > > Uhh...this doesn't seem legal to me. How can we just willy-nilly create a > store with a greater alignment? In this case Align is 8 and OrigAlign is > 16 > because SVT.getTypeForMVT() is Type::VectorTyID (<2 x i64>) which has an > ABI > type of VECTOR_ALIGN. > > Hmm...why is the ABI alignment for VectorTyID 16? The ABI certainly > doesn't > guarantee it. It only guarantees it for __int128, __float128 and __m128. > Lots of other types can map to <2 x i64>. > > Any opinions on this? > >...