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

find_reloads_address.bc

This
%tmp765 = load i64* %val ; [#uses=1]
%tmp766 = and i64 %tmp765, 15 ; [#uses=1]
is getting turned into this
%tmp765 = load i64* %val ; [#uses=1]
%sext = trunc i64 %tmp765 to 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 ; [#uses=1]
< %tmp767 = xor i64 %tmp766, 8 ; [#uses=1]
< %tmp768 = sub i64 %tmp767, 8 ; [#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!