[LLVMdev] [DragonEgg] Why Fortran's "call flush()" is converted to "call void bitcast (void (...)* @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind" ?

Dmitry N. Mikushin maemarcus at gmail.com
Tue Jul 17 13:16:59 PDT 2012


Thanks, Duncan, makes sense! I suppose you meant something like this:

                    Function* callee = dyn_cast<Function>(
                        call->getCalledValue()->stripPointerCasts());
                    if (!callee) continue;

- D.

2012/7/17 Duncan Sands <baldrick at free.fr>

> Hi Dmitry, it would be neater to use stripPointerCasts.
>
> Ciao, Duncan.
>
> > OK, at our end the following workaround seems to be sufficient:
> >
> >                      // Check if function is called (needs -instcombine
> pass).
> >                      Function* callee = call->getCalledFunction();
> >                      if (!callee)
> >                      {
> >                          // Could be also a function called inside a
> bitcast.
> >                          // So try to extract function from the
> underlying
> > constant expression.
> >                          // Required to workaround GCC/DragonEGG issue:
> >                          //
> > http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-July/051786.html
> >                          ConstantExpr* expr =
> > dyn_cast<ConstantExpr>(call->getCalledValue());
> >                          if (!expr) continue;
> >                          callee =
> dyn_cast<Function>(expr->getOperand(0));
> >                      }
> >
> > *Hopefully* there will be no more gcc-generated special cases :)
> >
> > Thanks,
> > - D.
> >
> > 2012/7/17 Duncan Sands <baldrick at free.fr <mailto:baldrick at free.fr>>
> >
> >     Hi Anton,
> >
> >
> >     On 17/07/12 15:35, Anton Korobeynikov wrote:
> >
> >             actually there is a different fix, which is to not pay any
> attention
> >             to GCC
> >             function types when generating calls (and function
> prototypes), and
> >             instead
> >             do everything by querying GCC's CUMULATIVE_ARGS.
> >
> >         I tried to do this during llvm-gcc times and it turned out that
> there
> >         might be different calls with different signatures in single
> module
> >         e.g. function with N arguments is called in some cases with N - 1
> >         first args and since the remaining one is unused everything is
> fine.
> >         So, basically the function *is* varargs but it's not possible to
> >         deduce this from the args...
> >
> >         I don't recall all the details now though...
> >
> >
> >     yes, it is a can of worms, but I'm hopeful it can be made to work
> anyway.
> >
> >     Ciao, Duncan.
> >
> >
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120717/d5eb1da5/attachment.html>


More information about the llvm-dev mailing list