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

Tobias Grosser tobias at grosser.es
Tue Feb 25 01:20:00 PST 2014


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Main-7adc26.sh
Type: application/x-shellscript
Size: 831 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140225/f49f92e5/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Main-7adc26.cpp
Type: text/x-c++src
Size: 939253 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140225/f49f92e5/attachment.cpp>


More information about the llvm-commits mailing list