Invalid type of 'ret' instruction

[asl]

Bugzilla Link	2723
Resolution	FIXED
Resolved on	Aug 26, 2008 16:04
Version	trunk
OS	Linux
Attachments	Preprocessed gzipped source
CC	@sunfishcode

Extended Description

Consider the attached preprocessed source. Here (x86-64/linux) I'm getting the following via 'llvm-g++ -O2':

define { double } @​_ZN7WebCore10FloatPoint15narrowPrecisionEdd(double %x, double %y) nounwind {
entry:
fptrunc double %y to float ; :0 [#uses=1]
fptrunc double %x to float ; :1 [#uses=1]
bitcast float %1 to i32 ; :2 [#uses=1]
zext i32 %2 to i64 ; :3 [#uses=1]
bitcast float %0 to i32 ; :4 [#uses=1]
zext i32 %4 to i64 ; :5 [#uses=1]
shl i64 %5, 32 ; :6 [#uses=1]
%.ins = or i64 %6, %3 ; [#uses=1]
%mrv8 = bitcast i64 %.ins to double ; [#uses=1]
ret double %mrv8
}

Note the type of function and type of 'ret'.

This makes inliner unhappy, due to assertion in RAUW. Verifier does not catch this case, btw.

This breaks webkit here.

[asl]

Btw, compilation with -fPIC even lead to assertions.

Reducing.

[sunfishcode]

The IR you posted is valid, due to compatibility with the LLVM 2.3 multiple return value
syntax. It is auto-upgraded to this:

%mrv = insertvalue { double } undef, double %mrv8, 0		; <{ double }> [#uses=1]
ret { double } %mrv

Is the inliner not handling this correctly?

[asl]

The IR you posted is valid, due to compatibility with the LLVM 2.3 multiple
return value
syntax. It is auto-upgraded to this:

    %mrv = insertvalue { double } undef, double %mrv8, 0            ; <{

double }> [#uses=1]
ret { double } %mrv

Is the inliner not handling this correctly?
When does this autoupgrade occur?

What I'm seeing: complation with 'llvm-gcc -O2 -fPIC' leads to assertion in RAUW, because it tries to inline this function. In particular - it tries to replace all uses of function of type {double} with return inst of type double and thus asserts.

I wasn't be able to reproduce this stuff on darwin (however, darwin llvm-gcc here is a bit old)

[sunfishcode]

Oh, the auto-upgrade happens at AsmParser or Bitcode reader time, so
llvm-g++ doesn't use it. So I guess this is an llvm-gcc bug. It's not supposed
to be using 2.3-style multiple return values anymore.

[asl]

Oh, the auto-upgrade happens at AsmParser or Bitcode reader time, so
llvm-g++ doesn't use it. So I guess this is an llvm-gcc bug. It's not supposed
to be using 2.3-style multiple return values anymore.

Aha, this explains, why I wasn't be able to reproduce bug with opt :) Anyway, here is reduced testcase. Let me know, if you want anything else.

[asl]

Reduced testcase

[asl]

Ok, I was able to reproduce problem on darwin also: just use 'llvm-g++ -O2 -m64'

[sunfishcode]

With this:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080825/066421.html
llvm-g++ now emits the proper code for first-class-aggregates.

[asl]

With this:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080825/066421.html
llvm-g++ now emits the proper code for first-class-aggregates.
This fixed it. Thanks!