<div dir="ltr">You missed the fix by 2 revisions. ;] r202129 should have fixed this. Sorry for the fallout!</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 25, 2014 at 3:19 AM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm still seeing them randomly failing 7zip on out test-suite bot:<br>
<br>
<a href="http://lab.llvm.org:8011/builders/clang-native-arm-lnt/builds/5326" target="_blank">http://lab.llvm.org:8011/builders/clang-native-arm-lnt/builds/5326</a><br>
<br>
1. <eof> parser at end of file<br>
2. Per-module optimization passes<br>
3. Running pass 'CallGraph Pass Manager' on module<br>
'/external/buildbot/clang-native-arm-lnt/test-suite/MultiSource/Benchmarks/7zip/CPP/7zip/Archive/PpmdHandler.cpp'.<br>
4. Running pass 'SROA' on function<br>
'@_ZN8NArchive5NPpmd8CHandler11GetPropertyEjjP14tagPROPVARIANT'<br>
clang: error: unable to execute command: Segmentation fault (core dumped)<br>
clang: error: clang frontend command failed due to signal (use -v to<br>
see invocation)<br>
clang version 3.5 (trunk 202127)<br>
<br>
cheers,<br>
--renato<br>
<div class="HOEnZb"><div class="h5"><br>
On 25 February 2014 09:20, Tobias Grosser <<a href="mailto:tobias@grosser.es">tobias@grosser.es</a>> wrote:<br>
> On 02/25/2014 01:07 AM, Chandler Carruth wrote:<br>
>><br>
>> Author: chandlerc<br>
>> Date: Mon Feb 24 18:07:09 2014<br>
>> New Revision: 202092<br>
>><br>
>> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=202092&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=202092&view=rev</a><br>
>> Log:<br>
>> [SROA] Fix another instability in SROA with respect to the slice<br>
>> ordering.<br>
>><br>
>> The fundamental problem that we're hitting here is that the use-def<br>
>> chain ordering is *itself* not a stable thing to be relying on in the<br>
>> rewriting for SROA. Further, we use a non-stable sort over the slices to<br>
>> arrange them based on the section of the alloca they're operating on.<br>
>> With a debugging STL implementation (or different implementations in<br>
>> stage2 and stage3) this can cause stage2 != stage3.<br>
>><br>
>> The specific aspect of this problem fixed in this commit deals with the<br>
>> rewriting and load-speculation around PHIs and Selects. This, like many<br>
>> other aspects of the use-rewriting in SROA, is really part of the<br>
>> "strong SSA-formation" that is doen by SROA where it works very hard to<br>
>> canonicalize loads and stores in *just* the right way to satisfy the<br>
>> needs of mem2reg[1]. When we have a select (or a PHI) with 2 uses of the<br>
>> same alloca, we test that loads downstream of the select are<br>
>> speculatable around it twice. If only one of the operands to the select<br>
>> needs to be rewritten, then if we get lucky we rewrite that one first<br>
>> and the select is immediately speculatable. This can cause the order of<br>
>> operand visitation, and thus the order of slices to be rewritten, to<br>
>> change an alloca from promotable to non-promotable and vice versa.<br>
>><br>
>> The fix is to defer all of the speculation until *after* the rewrite<br>
>> phase is done. Once we've rewritten everything, we can accurately test<br>
>> for whether speculation will work (once, instead of twice!) and the<br>
>> order ceases to matter.<br>
>><br>
>> This also happens to simplify the other subtlety of speculation -- we<br>
>> need to *not* speculate anything unless the result of speculating will<br>
>> make the alloca fully promotable by mem2reg. I had a previous attempt at<br>
>> simplifying this, but it was still pretty horrible.<br>
>><br>
>> There is actually already a *really* nice test case for this in<br>
>> basictest.ll, but on multiple STL implementations and inputs, we just<br>
>> got "lucky". Fortunately, the test case is very small and we can<br>
>> essentially build it in exactly the opposite way to get reasonable<br>
>> coverage in both directions even from normal STL implementations.<br>
><br>
><br>
> Hi Chandler,<br>
><br>
> I just noted a internal compiler error in SROA in the nightly test-suite<br>
> running 'clang -O3' (no Polly) that started between commit<br>
> 202088 and 202099. This commit seems the only SROA commit in this range.<br>
> I reported the problem here in <a href="http://llvm.org/PR18959" target="_blank">llvm.org/PR18959</a> and also included the<br>
> failing preprocessed source code. Maybe you would like to have a look.<br>
><br>
> Tobias<br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> llvm-commits mailing list<br>
> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
><br>
</div></div><br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>