Slightly tighter range I think is 262315:262388

Not too much in there that could affect us
r262352 - [X86] Check that attribute parameters match for tail calls (PR26590)
r262358 - DAGCombiner: Turn extract of bitcasted integer into truncate
r262370 - [X86] Elide references to _chkstk for dynamic allocas
r262376 - Fix an issue where fast math flags were dropped during scalarization
r262379 - [MSVC Compat] Correctly handle finallys nested within finallys

I strongly suspect our chkstk change. This failure appears to only affect 32-bit bots. We don't use inalloca on x64.

 Issue 591437  has been merged into this issue.

Pretty sure we crashed here:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/opus/src/src/analysis.c&l=262
    ALLOC(in, 480, kiss_fft_cpx);
    ALLOC(out, 480, kiss_fft_cpx);
    ALLOC(tonality, 240, float);
    ALLOC(noisiness, 240, float);

Together, the allocations require probing, but each individual allocation is less than 4096 bytes. There would be no bug if these were part of a call sequence, because the call always touches the top of the stack. So, we could limit our optimization to inalloca allocations, or revert and try to be more sophisticated later.

Reverted in r262505. We can get better code size savings if we tackle this problem a different way.