[polly] r252301 - Fix reuse of non-dominating synthesized value in subregion exit

Johannes Doerfert via llvm-commits llvm-commits at lists.llvm.org
Fri Nov 6 21:40:07 PST 2015


This actually caused 24 more failures, see:
  http://lab.llvm.org:8011/builders/perf-x86_64-penryn-O3-polly-unprofitable/builds/557

Before we were at 67, after at 91 and after r97986 we are now at 75,
see:
  http://lab.llvm.org:8011/builders/perf-x86_64-penryn-O3-polly-unprofitable/builds/569

This brings me to several problems I would like to discuss:
  1) Our "fixes" are not checked to be beneficial for more then the test
     case that was attached to the bug report (see above).
  2) The number of people looking at the lnt run and extracting tests is
     to little. Tobias complained in SJ about that, now it just
     shifted..
  3) We try to fix things one by one while the underlying problem is not
     exposed. Lately there are mainly dominance problems in non-affine
     regions (we see the 4th or 5th bug now). While they are all fixed
     by small changes to the code, it seems the changes always only
     fix that test case and sometimes even make things worse (see 1)). I
     would suggest to go back to the drawing board here and revert the
     change that introduced these problems (changed the scalar
     reload/store locations). Especially since we commited it
     preemptively and now might not need it anyways. Please bring
     forward counter arguments to this proposal.
  4) We __all__ have to get our priorities straight. If these bots are
     not green we cannot (or at least should not) commit anything new,
     though there is already new stuff pending for a while now that
     needs to be reviewed and decided on. The longer we wait the more
     work we all have...

Cheers,
  Johannes

On 11/06, Michael Kruse via llvm-commits wrote:
> Author: meinersbur
> Date: Fri Nov  6 07:51:24 2015
> New Revision: 252301
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=252301&view=rev
> Log:
> Fix reuse of non-dominating synthesized value in subregion exit
> 
> We were adding all generated values in non-affine subregions to be used
> for the subregions generated exit block. The thought was that only
> values that are dominating the original exit block can be used there.
> But it is possible for synthesizable values to be expanded in any
> block. If the same values is also used for implicit writes, it would
> try to reuse already synthesized values even if not dominating the exit
> block.
> 
> The fix is to only add values to the list of values usable in the exit
> block only if it is dominating the exit block. This fixes
> llvm.org/PR25412.
> 
> Added:
>     polly/trunk/test/Isl/CodeGen/non-affine-synthesized-in-branch.ll
> Modified:
>     polly/trunk/lib/CodeGen/BlockGenerators.cpp
> 
> Modified: polly/trunk/lib/CodeGen/BlockGenerators.cpp
> URL: http://llvm.org/viewvc/llvm-project/polly/trunk/lib/CodeGen/BlockGenerators.cpp?rev=252301&r1=252300&r2=252301&view=diff
> ==============================================================================
> --- polly/trunk/lib/CodeGen/BlockGenerators.cpp (original)
> +++ polly/trunk/lib/CodeGen/BlockGenerators.cpp Fri Nov  6 07:51:24 2015
> @@ -1074,7 +1074,8 @@ void RegionGenerator::copyStmt(ScopStmt
>          Blocks.push_back(*SI);
>  
>      // Remember value in case it is visible after this subregion.
> -    ValueMap.insert(RegionMap.begin(), RegionMap.end());
> +    if (DT.dominates(BB, R->getExit()))
> +      ValueMap.insert(RegionMap.begin(), RegionMap.end());
>    }
>  
>    // Now create a new dedicated region exit block and add it to the region map.
> 
> Added: polly/trunk/test/Isl/CodeGen/non-affine-synthesized-in-branch.ll
> URL: http://llvm.org/viewvc/llvm-project/polly/trunk/test/Isl/CodeGen/non-affine-synthesized-in-branch.ll?rev=252301&view=auto
> ==============================================================================
> --- polly/trunk/test/Isl/CodeGen/non-affine-synthesized-in-branch.ll (added)
> +++ polly/trunk/test/Isl/CodeGen/non-affine-synthesized-in-branch.ll Fri Nov  6 07:51:24 2015
> @@ -0,0 +1,30 @@
> +; RUN: opt -polly-process-unprofitable -polly-codegen -S < %s | FileCheck %s
> +;
> +; llvm.org/PR25412
> +; %synthgep caused %gep to be synthesized in subregion_if which was reused for
> +; %retval in subregion_exit, even though it is not dominating subregion_exit.
> +;
> +; CHECK-LABEL: polly.stmt.polly.merge_new_and_old.exit:
> +; CHECK:         %scevgep[[R1:[0-9]*]] = getelementptr %struct.hoge, %struct.hoge* %arg, i64 0, i32 2
> +; CHECK:         store double* %scevgep[[R1]], double** %gep.s2a
> +; CHECK:         br label
> +
> +%struct.hoge = type { double, double, double }
> +
> +define double @func(%struct.hoge* %arg) {
> +entry:
> +  br label %subregion_entry
> +
> +subregion_entry:
> +  %gep = getelementptr inbounds %struct.hoge, %struct.hoge* %arg, i64 0, i32 2
> +  %cond = fcmp ogt double undef, undef
> +  br i1 %cond, label %subregion_if, label %subregion_exit
> +
> +subregion_if:
> +  %synthgep = load double, double* %gep
> +  br label %subregion_exit
> +
> +subregion_exit:
> +  %retval = load double, double* %gep
> +  ret double %retval
> +}
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits

-- 

Johannes Doerfert
Researcher / PhD Student

Compiler Design Lab (Prof. Hack)
Saarland University, Computer Science
Building E1.3, Room 4.31

Tel. +49 (0)681 302-57521 : doerfert at cs.uni-saarland.de
Fax. +49 (0)681 302-3065  : http://www.cdl.uni-saarland.de/people/doerfert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151107/9b446742/attachment.sig>


More information about the llvm-commits mailing list