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
Hi Richard, On 18/09/14 19:25, Richard Gorton wrote:> > 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!you probably want to do the following: add a method for FPOWI in PromoteIntegerResult. In the method, get the i64 version of the second operand using: SDValue Op = SExtPromotedInteger(N->getOperand(1)); Create and return a new FPOWI node that is the same as the original, only it uses Op as the second operand. Ciao, Duncan.> > ------ > 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 > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
I'm missing something - I tried that, and also adding some code to PromoteIntegerOperand to do that, but get other errors. I submitted bug 21042 (with the .ll file as an example) On Sep 21, 2014, at 5:15 AM, Duncan Sands <duncan.sands at deepbluecap.com> wrote:> Hi Richard, > > On 18/09/14 19:25, Richard Gorton wrote: >> >> 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! > > you probably want to do the following: add a method for FPOWI in PromoteIntegerResult. In the method, get the i64 version of the second operand using: > SDValue Op = SExtPromotedInteger(N->getOperand(1)); > Create and return a new FPOWI node that is the same as the original, only it uses Op as the second operand. > > Ciao, Duncan. > >