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

[Renato Golin]

Oh, I see it building now. ;)

Thanks!
--renato

On 25 February 2014 11:28, Chandler Carruth <chandlerc at gmail.com> wrote:
> You missed the fix by 2 revisions. ;] r202129 should have fixed this. Sorry
> for the fallout!
>
>
> On Tue, Feb 25, 2014 at 3:19 AM, Renato Golin <renato.golin at linaro.org>
> wrote:
>>
>> 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
>> >
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>