[LLVMdev] troubles with ISD::FPOWI

Richard Gorton rcgorton at cognitive-electronics.com
Thu Sep 18 10:25:17 PDT 2014


Hi,

I'm stumped by how to handle fpowi.  Here is the context: my architecture has i64, f32, and f64 registers.  No i32.  For calls & returns, we promote i32 to i64.  There is no support in the architecture to perform fpowi - it has to go through the runtime.

I'm using gfortran + dragonegg + llvm3.4 to generate .ll files via plugin.
The fortran expression
	REAL = REAL ** INTEGER*4
Resulting in:
  %4 = call float @llvm.powi.f32(float %1, i32 %3)

So far, not unreasonable.
But when I run this through the compiler, it asserts:

-bash-4.1$ $DEVCLANG -target coge -O -S slamchf77.ll -mllvm -debug
...
Promote integer result: 0x56061c0: i32 = sub 0x56049a0, 0x56046a0 [ORD=161] [ID=0]

Promote integer operand: 0x56059c0: f32 = fpowi 0x5602580, 0x56061c0 [ORD=162] [ID=0]

PromoteIntegerOperand Op #1: 0x56059c0: f32 = fpowi 0x5602580, 0x56061c0 [ORD=162] [ID=0]

Do not know how to promote this operator's operand!

------
This is coming out of DAGTypeLegalizer::ExpandIntegerResult().
I've tried adding some code to expand the integer operand (operand 1) via SIGN_EXTEND[_INREG] but keep getting other consistency errors.

Another approach I tried was to set the calling convention:
	setLibcallCallingConv(RTLIB::POWI_F32, CallingConv::C);
Which would seem to force the call to convert the i32 --> i64 just like any other call, but that did not work either

Any suggestions (is this a real bug? - when I give other 64-bit targets, they also bomb out (sparcv9, aarch64)

Regards,

	Richard Gorton
	Cognitive Electronics
	www.cog-e.com





More information about the llvm-dev mailing list