[llvm-dev] Function calls keep increasing the stack usage

[Reid Kleckner via llvm-dev]

I think this is a bug in fastisel. It sometimes generates unnecessary
materializations like this. It's unclear why they end up getting spilled,
though.

On Fri, Sep 14, 2018 at 8:16 AM palpar via llvm-dev <llvm-dev at lists.llvm.org>
wrote:

> Hi everyone,
>
> I found that LLVM generates redundant code when calling functions with
> constant parameters, with optimizations disabled.
>
> Consider the following C code snippet:
>
> int foo(int x, int y);
>
> void bar()
> {
> foo(1, 2);
> foo(3, 4);
> }
>
> Clang/LLVM 6.0 generates the following assembly code:
> _bar:
> subl $32, %esp
> movl $1, %eax
> movl $2, %ecx
> movl $1, (%esp)
> movl $2, 4(%esp)
> movl %eax, 28(%esp)
> movl %ecx, 24(%esp)
> calll _foo
> movl $3, %ecx
> movl $4, %edx
> movl $3, (%esp)
> movl $4, 4(%esp)
> movl %eax, 20(%esp)
> movl %ecx, 16(%esp)
> movl %edx, 12(%esp)
> calll _foo
> movl %eax, 8(%esp)
> addl $32, %esp
> retl
>
> Note how the constants are stored in registers but when saving the
> parameters on the stack for the call the immediate values are used. The
> registers are still stored on the stack probably because it's the caller's
> responsibility once they were used (which seems expected).
> I think the problem comes from the fact that LLVM unconditionally
> allocates a register for each parameter value regardless if it's used later
> or not.
> If the stack space of the program is sufficiently large this is probably
> not a problem, but otherwise if there is a large number of such calls,
> despite not recursive, it can lead to stack overflow. Do you think I should
> create a bug report for this?
>
> (Similarly, the return value of the function could be not saved but the
> LLVM IR code that Clang generates has the call with assignment so at this
> point LLVM couldn't possibly know.
> define void @bar() #0 {
>   %call = call i32 @foo(i32 1, i32 2)
>   %call1 = call i32 @foo(i32 3, i32 4)
>   ret void
> }
> )
>
> Thanks,
> Alpar
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180914/0c93586e/attachment.html>