laurov@laurov-desktop:~/llvm/llvm/build$ llc -march=x86 bugpoint-reduced-simplified.bc llc: /home/laurov/llvm/llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp:2257: llvm::MVT::ValueType llvm::TargetLowering::getValueType(const llvm::Type*) const: Assertion `0 && "Invalid width for value type"' failed. llc((anonymous namespace)::PrintStackTrace()+0x1a)[0x88d7886] llc((anonymous namespace)::SignalHandler(int)+0x112)[0x88d7b4c] [0xffffe420] /lib/tls/i686/cmov/libc.so.6(abort+0x103)[0xb7cdfef3] /lib/tls/i686/cmov/libc.so.6(__assert_fail+0xfb)[0xb7cd7dbb] llc(llvm::TargetLowering::getValueType(llvm::Type const*) const+0xbf)[0x868dff9] llc(llvm::SelectionDAGLowering::getValue(llvm::Value const*)+0xaa)[0x8660a3c] llc(llvm::SelectionDAGLowering::visitSExt(llvm::User&)+0x30)[0x866b834] llc(llvm::SelectionDAGLowering::visit(unsigned int, llvm::User&)+0x2eb)[0x8688df9] llc(llvm::SelectionDAGLowering::visit(llvm::Instruction&)+0x28)[0x8688fde] llc(llvm::SelectionDAGISel::BuildSelectionDAG(llvm::SelectionDAG&, llvm::BasicBlock*, std::vector<std::pair<llvm::MachineInstr*, unsigned int>, std::allocator<std::pair<llvm::MachineInstr*, unsigned int> > >&, llvm::FunctionLoweringInfo&)+0x14a)[0x866f26e] llc(llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*, llvm::MachineFunction&, llvm::FunctionLoweringInfo&)+0x98)[0x866fcd4] llc(llvm::SelectionDAGISel::runOnFunction(llvm::Function&)+0x5d2)[0x86714e6] llc[0x853a0ed] llc(llvm::FPPassManager::runOnFunction(llvm::Function&)+0x13a)[0x88639a6] llc(llvm::FunctionPassManagerImpl::run(llvm::Function&)+0x6e)[0x8863c2a] llc(llvm::FunctionPassManager::run(llvm::Function&)+0x88)[0x8863cea] llc(main+0xbe9)[0x83d6bdd] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc)[0xb7cca8cc] llc(__gxx_personality_v0+0x175)[0x83d4f11] Aborted (core dumped)
Created attachment 729 [details] bugpoint-reduced-simplified.bc
When does llvm-gcc emit this?
llvm-gcc emits this when it compiles the gcc/reload.c file. [sbox-n770: /llvm/llvm-gcc/build/gcc] > /llvm/llvm-gcc/build/prev-gcc/xgcc -B/llvm/llvm-gcc/build/prev-gcc/ -B/usr/local/arm-linux-gnueabi/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -fno-common -DHAVE_CONFIG_H -DENABLE_LLVM -D__STDC_LIMIT_MACROS -I. -I. -I/llvm/llvm-gcc/gcc -I/llvm/llvm-gcc/gcc/. -I/llvm/llvm-gcc/gcc/../include -I/llvm/llvm-gcc/gcc/../libcpp/include -I/llvm/llvm/include -I/llvm/llvm/build//include /llvm/llvm-gcc/gcc/reload.c -o reload.o cc1: /llvm/llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp:2257: llvm::MVT::ValueType llvm::TargetLowering::getValueType(const llvm::Type*) const: Assertion `0 && "Invalid width for value type"' failed. /llvm/llvm-gcc/gcc/reload.c:7231: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://llvm.org/bugs> for instructions.
If so, that sounds like a serious bug. Duncan/Devang, could this be related to recent struct layout/bitfield work?
lauro, does this happen with -O0 ? If it happens with -O2 but not -O0, please attach the -O0 -emit- llvm .bc file, thanks!
The "sext i4 to i64" is emitted when llvm optimizes the function find_reloads_address. laurov@laurov-desktop:/tmp$ opt -std-compile-opts find_reloads_address.bc | llc llc: /home/laurov/llvm/llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp:2257: llvm::MVT::ValueType llvm::TargetLowering::getValueType(const llvm::Type*) const: Assertion `0 && "Invalid width for value type"' failed. ...
Created attachment 730 [details] find_reloads_address.bc
This %tmp765 = load i64* %val ; <i64> [#uses=1] %tmp766 = and i64 %tmp765, 15 ; <i64> [#uses=1] is getting turned into this %tmp765 = load i64* %val ; <i64> [#uses=1] %sext = trunc i64 %tmp765 to i4 ; <i4> [#uses=1] which is perfectly logical.
Reid, will you please look into this? It sounds like an instcombine regression from your changes. instcombine should never introduce "nonstandard" width integers, at least not yet. -Chris
The transform being done is this: < %tmp766 = and i64 %tmp765, 15 ; <i64> [#uses=1] < %tmp767 = xor i64 %tmp766, 8 ; <i64> [#uses=1] < %tmp768 = sub i64 %tmp767, 8 ; <i64> [#uses=1] --- > %sext = trunc i64 %tmp765 to i4 ; <i4> [#uses=1] > %tmp768 = sext i4 %sext to i64 ; <i64> [#uses=1] The only place that a "trunc" is created with name "sext" and the only place where IntegerType::get() is called (to make the i4) is in visitAdd. I assume the sub is turned into an add of -8 first. This is part of one of the more complex transforms that Sheng did. I'm going to revert that part of his patch. Either that or I can just quantize it to a PowOf2 sized integer.
Fixed with this patch: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070326/046325.html Test case here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070326/046326.html
Thanks Reid!