[llvm-dev] Where's the optimiser gone? (part 5.b): missed tail calls, and more...
Craig Topper via llvm-dev
llvm-dev at lists.llvm.org
Sat Dec 1 12:20:25 PST 2018
On Sat, Dec 1, 2018 at 12:05 PM Stefan Kanthak <stefan.kanthak at nexgo.de>
wrote:
> "Craig Topper" <craig.topper at gmail.com> wrote:
>
>
> > Clang's -target option is supposed to take a cpu type and an operating
> > system. So "-target i386" is giving it no operatiing system. This is
> > preventing frame pointer elimination which is why ebp is being updated.
> If
> > you pass "-target i386-linux" you get sightly better code.
>
> The frame pointer is but not the point here.
>
You didn't provide what you think the improved code would be for the
multiply. So I wasn't sure.
>
> > The division/remainder operations are turned into library calls as part
> of
> > instruction selection. This code is somewhat independent of how other
> calls
> > are handled. We probably don't support tail calls in it. Is it really
> > realistic that a user would have a non-inlined function that contains
> just
> > a division? Why should we optimize for that case?
>
> I've seen quite some libraries which implement such functions, calling
> just another function having the same prototype, as target-independent
> wrappers.
> So the question is not whether it's just a division, but in general the
> call of a function having the same prototype.
>
We do support that when there is a call in the original source code. The
division/remainder case is special because we're turning an arithmetic
operation into a call. This for example works.
long long foo(long long x, long long y) {
return bar(foo, bar);
}
>
> regards
> Stefan
>
> > On Sat, Dec 1, 2018 at 9:37 AM Stefan Kanthak via llvm-dev <
> > llvm-dev at lists.llvm.org> wrote:
> >
> >> Compile the following functions with "-O3 -target i386"
> >> (see <https://godbolt.org/z/VmKlXL>):
> >>
> >> long long div(long long foo, long long bar)
> >> {
> >> return foo / bar;
> >> }
> >>
> >> On the left the generated code; on the right the expected,
> >> properly optimised code:
> >>
> >> div: # @div
> >> push ebp |
> >> mov ebp, esp |
> >> push dword ptr [ebp + 20] |
> >> push dword ptr [ebp + 16] |
> >> push dword ptr [ebp + 12] |
> >> push dword ptr [ebp + 8] |
> >> call __divdi3 | jmp __divdi3
> >> add esp, 16 |
> >> pop ebp |
> >> ret |
> >>
> >>
> >> long long mod(long long foo, long long bar)
> >> {
> >> return foo % bar;
> >> }
> >>
> >> mod: # @mod
> >> push ebp |
> >> mov ebp, esp |
> >> push dword ptr [ebp + 20] |
> >> push dword ptr [ebp + 16] |
> >> push dword ptr [ebp + 12] |
> >> push dword ptr [ebp + 8] |
> >> call __moddi3 | jmp __moddi3
> >> add esp, 16 |
> >> pop ebp |
> >> ret |
> >>
> >>
> >> long long mul(long long foo, long long bar)
> >> {
> >> return foo * bar;
> >> }
> >>
> >> mul: # @mul
> >> push ebp
> >> mov ebp, esp
> >> push esi
> >> mov ecx, dword ptr [ebp + 16]
> >> mov esi, dword ptr [ebp + 8]
> >> mov eax, ecx
> >> imul ecx, dword ptr [ebp + 12]
> >> mul esi
> >> imul esi, dword ptr [ebp + 20]
> >> add edx, ecx
> >> add edx, esi
> >> pop esi
> >> pop ebp
> >> ret
> >> _______________________________________________
> >> 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/20181201/3cb53c4d/attachment.html>
More information about the llvm-dev
mailing list