[PATCH] D12072: [FIX] Restrict the AST build with the assumed context

Johannes Doerfert via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 17 01:48:59 PDT 2015


You are correct about the hiding and the problem was just a wrong
assumption made in the scalar code generation. I fixed that one and
updated the test. Thanks for the illustrating example.

Do we want to use the assumed context restriction patch anyway or not?

> Hi Johannes,
> 
> thanks for the interesting test case.
> 
> >jdoerfert created this revision.
> >jdoerfert added reviewers: grosser, Meinersbur.
> >jdoerfert added a subscriber: Polly.
> >
> >   This is necessary as the dependence analysis is restricted by the
> >   assumed context as well and the AST generation needs to be in-sync.
> >   Otherwise this might generate not executed code that will crash the
> >   scalar code generation. Additionally, this change can simplify the AST
> >   as less conditions and code needs to be generated.
> 
> This change may indeed make sense, but my feeling is that it only hides the
> bug rather than actually solves it.
> 
> This is for two reasons:
> 
> 1) The AST generator is not guaranteed to exploit the context.
> 2) The AST generator is not guaranteed to ensure a certain _textual_ order.
> 
> To my understanding it seems the scalar code generation has somehow a requirement
> on the textual order code is emitted in. Is this right? Why is this needed?
> 
> The issue is that two statements with dependences A(i) -> B(i) can theoretically
> be code generated in the following way:
> 
> for (i = 0; i <= n; i++) {
>   if (i > 0)
>     B(i-1);
>    A(i)
> }
> B(n);
> 
> This means, even though A(i) is guaranteed to be executed before B(i), their actual
> textual order may be reversed.
> 
> In general we avoid this issue by _always_ going through memory, such that there is no
> dominance needed, but such that for a valid execution the temporal order of memory
> accesses is correct.
> 
> Best,
> Tobias
> 
> 
> 
> 
> 
> >Index: test/Isl/CodeGen/assumed_context_empty_domain_restriction.ll
> >===================================================================
> >--- test/Isl/CodeGen/assumed_context_empty_domain_restriction.ll
> >+++ test/Isl/CodeGen/assumed_context_empty_domain_restriction.ll
> >@@ -1,18 +1,19 @@
> >-; RUN: opt %loadPolly -S -polly-opt-isl -polly-codegen < %s
> >+; RUN: opt %loadPolly -S -polly-opt-isl -polly-ast -analyze < %s | FileCheck --check-prefix=AST %s
> >+; RUN: opt %loadPolly -S -polly-opt-isl -polly-codegen < %s | FileCheck %s
> >  ;
> >-; TODO: This test will crash the scalar code generation. The problem step by step:
> >-;         1) The assumed context is empty because of the out-of-bounds array access.
> >-;         2) The dependence analysis will use the assumed context and determine
> >-;            that there are not iterations executed, hence no dependences.
> >-;         3) The scheduler will transform the program somehow according to
> >-;            the orginal domains and empty dependences but not the assumed context.
> >-;            The new ast is shown below.
> >-;         4) The code generation will look for the new value of %0 when the
> >-;            for_body_328_lr_ph statement is copied, however it has not yet seen %0
> >-;            as the for_end_310 statement has been moved after for_body_328_lr_ph.
> >-;         5) Crash as no new value of %0 can be found.
> >+; This test crashed the scalar code generation. The problem step by step:
> >+;   1) The assumed context is empty because of the out-of-bounds array access.
> >+;   2) The dependence analysis will use the assumed context and determine
> >+;      that there are not iterations executed, hence no dependences.
> >+;   3) The scheduler will transform the program somehow according to
> >+;      the orginal domains and empty dependences but not the assumed context.
> >+;      The new and the old ast is shown below.
> >+;   4) The code generation will look for the new value of %0 when the
> >+;      for_body_328_lr_ph statement is copied, however it has not yet seen %0
> >+;      as the for_end_310 statement has been moved after for_body_328_lr_ph.
> >+;   5) Crash as no new value of %0 can be found.
> >  ;
> >-; AST:
> >+; AST old:
> >  ;
> >  ;   if (0)
> >  ;       {
> >@@ -24,11 +25,12 @@
> >  ;   else
> >  ;       {  /* original code */ }
> >  ;
> >-; CHECK: polly.start
> >-;
> >-; TODO: This test should not crash Polly.
> >+; AST new:
> >+; AST:  if (0)
> >+; AST:    {
> >+; AST:    }
> >  ;
> >-; XFAIL: *
> >+; CHECK: polly.start
> >  ;
> >  @endposition = external global i32, align 4
> >  @Bit = external global [0 x i32], align 4
> >Index: lib/CodeGen/IslAst.cpp
> >===================================================================
> >--- lib/CodeGen/IslAst.cpp
> >+++ lib/CodeGen/IslAst.cpp
> >@@ -416,6 +416,13 @@
> >
> >    buildRunCondition(Build);
> >
> >+  // The assumed context restricts the dependence analysis, hence it also has
> >+  // to restrict the AST generation otherwise the scalar code generation can
> >+  // become unstable. However, we need to do this after we generated the runtime
> >+  // checks as the context we use to restrict the AST generation with only holds
> >+  // if the runtime checks are true.
> >+  Build = isl_ast_build_restrict(Build, S->getAssumedContext());
> >+
> >    Root = isl_ast_build_node_from_schedule(Build, S->getScheduleTree());
> >
> >    isl_ast_build_free(Build);
> >
> >
> 

-- 

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: not available
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150817/5cd2b8b9/attachment.sig>


More information about the llvm-commits mailing list