[llvm] r202092 - [SROA] Fix another instability in SROA with respect to the slice

[Renato Golin]

I'm still seeing them randomly failing 7zip on out test-suite bot:

http://lab.llvm.org:8011/builders/clang-native-arm-lnt/builds/5326

1. <eof> parser at end of file
2. Per-module optimization passes
3. Running pass 'CallGraph Pass Manager' on module
'/external/buildbot/clang-native-arm-lnt/test-suite/MultiSource/Benchmarks/7zip/CPP/7zip/Archive/PpmdHandler.cpp'.
4. Running pass 'SROA' on function
'@_ZN8NArchive5NPpmd8CHandler11GetPropertyEjjP14tagPROPVARIANT'
clang: error: unable to execute command: Segmentation fault (core dumped)
clang: error: clang frontend command failed due to signal (use -v to
see invocation)
clang version 3.5 (trunk 202127)

cheers,
--renato

On 25 February 2014 09:20, Tobias Grosser <tobias at grosser.es> wrote:
> On 02/25/2014 01:07 AM, Chandler Carruth wrote:
>>
>> Author: chandlerc
>> Date: Mon Feb 24 18:07:09 2014
>> New Revision: 202092
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=202092&view=rev
>> Log:
>> [SROA] Fix another instability in SROA with respect to the slice
>> ordering.
>>
>> The fundamental problem that we're hitting here is that the use-def
>> chain ordering is *itself* not a stable thing to be relying on in the
>> rewriting for SROA. Further, we use a non-stable sort over the slices to
>> arrange them based on the section of the alloca they're operating on.
>> With a debugging STL implementation (or different implementations in
>> stage2 and stage3) this can cause stage2 != stage3.
>>
>> The specific aspect of this problem fixed in this commit deals with the
>> rewriting and load-speculation around PHIs and Selects. This, like many
>> other aspects of the use-rewriting in SROA, is really part of the
>> "strong SSA-formation" that is doen by SROA where it works very hard to
>> canonicalize loads and stores in *just* the right way to satisfy the
>> needs of mem2reg[1]. When we have a select (or a PHI) with 2 uses of the
>> same alloca, we test that loads downstream of the select are
>> speculatable around it twice. If only one of the operands to the select
>> needs to be rewritten, then if we get lucky we rewrite that one first
>> and the select is immediately speculatable. This can cause the order of
>> operand visitation, and thus the order of slices to be rewritten, to
>> change an alloca from promotable to non-promotable and vice versa.
>>
>> The fix is to defer all of the speculation until *after* the rewrite
>> phase is done. Once we've rewritten everything, we can accurately test
>> for whether speculation will work (once, instead of twice!) and the
>> order ceases to matter.
>>
>> This also happens to simplify the other subtlety of speculation -- we
>> need to *not* speculate anything unless the result of speculating will
>> make the alloca fully promotable by mem2reg. I had a previous attempt at
>> simplifying this, but it was still pretty horrible.
>>
>> There is actually already a *really* nice test case for this in
>> basictest.ll, but on multiple STL implementations and inputs, we just
>> got "lucky". Fortunately, the test case is very small and we can
>> essentially build it in exactly the opposite way to get reasonable
>> coverage in both directions even from normal STL implementations.
>
>
> Hi Chandler,
>
> I just noted a internal compiler error in SROA in the nightly test-suite
> running 'clang -O3' (no Polly) that started between commit
> 202088 and 202099. This commit seems the only SROA commit in this range.
> I reported the problem here in llvm.org/PR18959 and also included the
> failing preprocessed source code. Maybe you would like to have a look.
>
> Tobias
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PpmdHandler-ce3a29.cpp
Type: text/x-c++src
Size: 830934 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140225/98a545ff/attachment.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PpmdHandler-ce3a29.sh
Type: application/x-sh
Size: 832 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140225/98a545ff/attachment.sh>