[PATCH] InstCombine: allow converting varargs calls to non-varargs.

[Will Dietz via llvm-commits]

On Thu, Mar 10, 2016 at 5:18 PM Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
>
> On Thu, Mar 10, 2016 at 05:00:50PM +0000, Will Dietz via llvm-commits wrote:
> > declare i32 @test17x(i32)
> > define i32 @test17(i32 %arg) {
> > entry:
> >   %call = call i32 (...) bitcast (i32 (i32)* @test17x to i32 (...)*)(i32
> > %arg)
> >   ret i32 %call
> > }
> >
> > by simplifying into:
> >
> > define i32 @test17(i32 %arg) {
> > entry:
> >   %call = call i32 @test17x(i32 %arg)
> >   ret i32 %call
> > }
> >
> > If this is not something InstCombine should do (ABI concerns perhaps?),
>
> Are you sure this doesn't break e.g. x86_64 or other platforms that tag
> the use of FP registers for variadic functions?
>

I don't believe it would unless the signature of the declaration is incorrect.

If that's true, I think this comes down to how well LLVM trusts declarations.

It seems to me that LLVM should trust declarations as a default rule,
and add exceptions only as is needed to avoid problems when dealing
with "real code".

For example, at one point it was considered a bug for InstCombine to
'trust' a declaration
indicating var-args[1].  I don't know for sure the full reasoning for
this, but I believe it's due to
the practice in C of either simply declaring functions as var-args
just because you can,
or due to the C frontend using var-args signatures to model calls to
functions without prototypes[2].
As a result, InstCombine was taught to not trust declarations claiming
functions are var-args.

On the other hand, I'm not sure there's a similar reason to not trust
the signature of a declaration
claiming a function is /not/ var-args.  Or is there?

---------

For a bit of context, my motivation here is to help LLVM make IR like
this simpler in order to better facilitate analysis.  Fixing this
pattern is surprisingly useful since the bitcast makes the call
"indirect", marks the function as address-taken, and makes
interprocedural analysis more difficult than it needs to be for such a
simple call :).  This seems like a somewhat common scenario, where you
know the signatures of functions in other modules (such as libc) but
would like to analyze things in their current partitioning (not
linking in their definitions, which is what is required to convince
InstCombine to remove the bitcast in the current implementation).

Thank you for your time,

~Will

[1] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20110221/117036.html
[2] http://lists.llvm.org/pipermail/llvm-dev/2007-September/010708.html