[llvm-commits] Issue with Win64 local area stack offset

[NAKAMURA Takumi]

Anton,

2010/9/3 Anton Korobeynikov <anton at korobeynikov.info>:
>> Any comments about the revised patch? Ok for someone to commit?
> The patch is invalid. First of all, make sure it does not break "make check".
> Right now it does and one of the failed tests clearly indicates the
> problem - the shadow space is allocated in the wrong place and calls
> might clobber spills of the callee which will be really hard to find
> in real-world apps.

I don't understand what would be wrong with it.
I built r112883 and got two failures.

Failing Tests (2):
    LLVM :: CodeGen/X86/2009-06-03-Win64DisableRedZone.ll
    LLVM :: CodeGen/X86/2009-06-03-Win64SpillXMM.ll

They might be as same as what you met.
http://lists.cs.uiuc.edu/pipermail/llvm-testresults/2010-September/028878.html

I would like to know if others else two went worse.

The results themselves did emit good sequences.

# 2009-06-03-Win64DisableRedZone.ll
a:
        subq    $8, %rsp
        movq    %rcx, (%rsp)
        fildll  (%rsp)
        addq    $8, %rsp
        ret

It is a *leaf* function and broke nothing.
Shadow area would not be needed for the function "a* to allocate.
It would be better as below if we could.
a:
        movq    %rcx, 8(%rsp)
        fildll  8(%rsp)
        ret

# 2009-06-03-Win64SpillXMM.ll
a:
        subq    $40, %rsp
        movaps  %xmm8, (%rsp)           # 16-byte Spill
        movaps  %xmm7, 16(%rsp)         # 16-byte Spill
        #APP
        #NO_APP
        movaps  16(%rsp), %xmm7         # 16-byte Reload
        movaps  (%rsp), %xmm8           # 16-byte Reload
        addq    $40, %rsp
        ret

It would be reasonable and broke nothing, too.
"asm" might not be assumed to use shadow area.


Thank you, ...Takumi