[llvm-commits] patch: use addressing modes for "m" constraints fed by bitcast/GEP

[Eli Friedman]

On Fri, Sep 30, 2011 at 3:26 PM, Nick Lewycky <nlewycky at google.com> wrote:
> The attached patch eagerly evaluates bitcasts and GEPs feeding inline
> assembly constraints. That reduces the chance that we'll copy the
> result into a register. On this testcase:
>
> void test(short *a,short *b,float *c) {
>    char tmp[256];
>    __asm__ volatile(
>        "%0 %1 %2 %3 %4"
>        :
>        :"m"(a),"m"(b),"m"(c),"m"(tmp[0]), "m"(tmp[128])
>        :"memory","%eax","%ebx","%ecx","%edx","%esi","%edi");
> }
>
> previously we'd run out of registers. Now, we emit:
>
>        pushl   %ebx
>        pushl   %edi
>        pushl   %esi
>        subl    $268, %esp              # imm = 0x10C
>        movl    292(%esp), %eax
>        movl    288(%esp), %ecx
>        movl    284(%esp), %edx
>        movl    %edx, 264(%esp)
>        movl    %ecx, 260(%esp)
>        movl    %eax, 256(%esp)
>        #APP
>        264(%esp) 260(%esp) 256(%esp) (%esp) 128(%esp)
>        #NO_APP
>        addl    $268, %esp              # imm = 0x10C
>        popl    %esi
>        popl    %edi
>        popl    %ebx
>        ret
>
> which clearly has an extra copy, but that's a bug which existed
> without my patch anyways. The tmp[0] and tmp[128] don't have any
> copies.
>
> Please review!

I follow the concept, but I don't think the place you're hacking it in
is really appropriate.  This is a fast-isel-specific problem, so it
seems like the fix should also be in fast-isel code.

-Eli