[Webkit-unassigned] [Bug 144136] Better optimize 'if' with ternaries conditional tests.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=144136

--- Comment #5 from Filip Pizlo <fpizlo at apple.com> ---
(In reply to comment #4)
> (In reply to comment #1)
> > This might be a hole in LLVM's CFG transforms.  It might also just be a
> > matter of running some LLVM phase that we currently fail to run.
> > 
> > What about the generated machine code for "if (a?b:0)" is better than the
> > code for "if (a && b)"?
> 
> The main loops for the two attached examples:
> 
> slow:
>       0x7f198a000330: movzbl  %bl, %eax
>       0x7f198a000333: movzbl  (%rax,%r15), %ecx
>       0x7f198a000338: cmpl    $1, %ecx
>       0x7f198a00033b: jne     0x7f198a000370
>       0x7f198a00033d: movzbl  1(%rax,%r15), %ecx
>       0x7f198a000343: cmpl    $2, %ecx
>       0x7f198a000346: jne     0x7f198a000370
>       0x7f198a000348: movzbl  2(%rax,%r15), %ecx
>       0x7f198a00034e: cmpl    $3, %ecx
>       0x7f198a000351: jne     0x7f198a000370
>       0x7f198a000353: movzbl  3(%rax,%r15), %eax
>       0x7f198a000359: cmpl    $4, %eax
>       0x7f198a00035c: sete    %al
>       0x7f198a00035f: movzbl  %al, %eax

Oh wow, this sequence is really dumb.

>       0x7f198a000362: jmp     0x7f198a000390
>       0x7f198a000364: nopw    %cs:(%rax,%rax)
>       0x7f198a000370: movl    $2147483648, 36(%rbp)
>       0x7f198a000377: leaq    131779232(%r15), %rax
>       0x7f198a00037e: movq    %rbp, %rdi
>       0x7f198a000381: movq    %r14, %rsi
>       0x7f198a000384: callq   *%rax
>       0x7f198a000386: cmpq    $0, -2216120(%r15)
>       0x7f198a00038e: jne     0x7f198a0003b6
>       0x7f198a000390: testq   %rax, %rax
>       0x7f198a000393: cmovnel %r13d, %r12d

Yuck!

>       0x7f198a000397: incl    %ebx
>       0x7f198a000399: cmpl    $1000000000, %ebx
>       0x7f198a00039f: jl      0x7f198a000330
> 
> fast:
>       0x7f81720002e0: movzbl  %cl, %edi
>       0x7f81720002e3: movzbl  (%rdi,%rax), %esi
>       0x7f81720002e7: cmpl    $1, %esi
>       0x7f81720002ea: jne     0x7f8172000320
>       0x7f81720002ec: movzbl  1(%rdi,%rax), %esi
>       0x7f81720002f1: cmpl    $2, %esi
>       0x7f81720002f4: jne     0x7f8172000320
>       0x7f81720002f6: movzbl  2(%rdi,%rax), %esi
>       0x7f81720002fb: cmpl    $3, %esi
>       0x7f81720002fe: jne     0x7f8172000320
>       0x7f8172000300: movzbl  3(%rdi,%rax), %esi
>       0x7f8172000305: movl    $1, %edi
>       0x7f817200030a: cmpl    $4, %esi
>       0x7f817200030d: je      0x7f8172000311
>       0x7f817200030f: movl    %edx, %edi
>       0x7f8172000311: movl    %edi, %edx
>       0x7f8172000313: nopw    %cs:(%rax,%rax)
>       0x7f8172000320: incl    %ecx
>       0x7f8172000322: cmpl    $1000000000, %ecx
>       0x7f8172000328: jl      0x7f81720002e0

Yup, LLVM bug.  Maybe we can work around it - but it seems that this should be fixed in LLVM.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150424/3e717b39/attachment.html>