[llvm-commits] [llvm] r140107 - in /llvm/trunk/test/CodeGen/X86: 2006-05-11-InstrSched.ll 2009-06-05-ScalarToVectorByteMMX.ll movgs.ll v2f32.ll vec_set-C.ll

[Eli Friedman]

On Tue, Sep 20, 2011 at 4:51 PM, Bruno Cardoso Lopes
<bruno.cardoso at gmail.com> wrote:
> Hi Eli,
>
>> I think there's a real regression here... I'm pretty sure you "broke"
>> the fix in r100559 (see also
>> http://llvm.org/bugs/show_bug.cgi?id=6696).  Not sure how much we
>> care, though.
>
> I actually care, but if you follow it closely, you're going to notice
> that all getReserveFP() calls introduced in r100559, were removed
> afterwards (I can't find it in the history where that happened though)

Jakob did that, I think (132199 etc.).

> and this didn't trigger PR6696 for Linux, explanation: In the mean
> time Linux stack default alignment was changed to 128-bit, and the
> stack alignment heuristic was never needed anymore. It reappeared for
> AVX, because of the explanation I wrote in r139939's commit message.
> Besides that, when I replaced getReserveFP() for
> getForceFramePointer() in X86MaxStackAlignmentHeuristicPass, all I
> actually did was to restore the behavior added in r100559, which isn't
> needed anymore for Linux because of the 128-bit alignment. Anyway, if
> you have any concrete example where it did break, let me know!

With the current state on trunk, there's a missed optimization on
Windows with -fomit-frame-pointer and SSE, and on all platforms with
-fomit-frame-pointer and AVX: we build the frame pointer when it isn't
necessary.  Granted, it isn't really such a great optimization
considering that the execution cost of any vector code is likely to be
much greater than the cost of pushing and popping the frame pointer,
but it was working at one point.

-Eli