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

[Chandler Carruth]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140225/5f1c44a1/attachment.html>