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

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>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120717/4cfa6257/attachment.html>

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
>

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>