maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/polly/test/Isl/CodeGen/synthesizable_phi_write_aft...

40 lines
1.0 KiB
LLVM
Raw Normal View History

BlockGenerators: Replace getNewScalarValue with getNewValue Both functions implement the same functionality, with the difference that getNewScalarValue assumes that globals and out-of-scop scalars can be directly reused without loading them from their corresponding stack slot. This is correct for sequential code generation, but causes issues with outlining code e.g. for OpenMP code generation. getNewValue handles such cases correctly. Hence, we can replace getNewScalarValue with getNewValue. This is not only more future proof, but also eliminates a bunch of code. The only functionality that was available in getNewScalarValue that is lost is the on-demand creation of scalar values. However, this is not necessary any more as scalars are always loaded at the beginning of each basic block and will consequently always be available when scalar stores are generated. As this was not the case in older versions of Polly, it seems the on-demand loading is just some older code that has not yet been removed. Finally, generateScalarLoads also generated loads for values that are loop invariant, available in GlobalMap and which are preferred over the ones loaded in generateScalarLoads. Hence, we can just skip the code generation of such scalar values, avoiding the generation of dead code. Differential Revision: http://reviews.llvm.org/D16522 llvm-svn: 258799
2016-01-26 18:01:35 +08:00
; RUN: opt %loadPolly -polly-codegen -S < %s | FileCheck %s
;
; Check for the correct written value of a scalar phi write whose value is
; defined within the loop, but its effective value is its last definition when
; leaving the loop (in this test it is the value 2 for %i.inc). This can be
; either computed:
; - Using SCEVExpander:
; In this case the Loop passed to the expander must NOT be the loop
; - Overwriting the same alloca in each iteration s.t. the last value will
; retain in %i.inc.s2a
ScopInfo: Never add read accesses for synthesizable values Before adding a MK_Value READ MemoryAccess, check whether the read is necessary or synthesizable. Synthesizable values are later generated by the SCEVExpander and therefore do not need to be transferred explicitly. This can happen because the check for synthesizability has presumbly been forgotten in the case where a phi's incoming value has been defined in a different statement. Differential Revision: http://reviews.llvm.org/D15687 llvm-svn: 258998
2016-01-28 06:51:56 +08:00
; The first is currently generated by Polly and tested here.
BlockGenerators: Replace getNewScalarValue with getNewValue Both functions implement the same functionality, with the difference that getNewScalarValue assumes that globals and out-of-scop scalars can be directly reused without loading them from their corresponding stack slot. This is correct for sequential code generation, but causes issues with outlining code e.g. for OpenMP code generation. getNewValue handles such cases correctly. Hence, we can replace getNewScalarValue with getNewValue. This is not only more future proof, but also eliminates a bunch of code. The only functionality that was available in getNewScalarValue that is lost is the on-demand creation of scalar values. However, this is not necessary any more as scalars are always loaded at the beginning of each basic block and will consequently always be available when scalar stores are generated. As this was not the case in older versions of Polly, it seems the on-demand loading is just some older code that has not yet been removed. Finally, generateScalarLoads also generated loads for values that are loop invariant, available in GlobalMap and which are preferred over the ones loaded in generateScalarLoads. Hence, we can just skip the code generation of such scalar values, avoiding the generation of dead code. Differential Revision: http://reviews.llvm.org/D16522 llvm-svn: 258799
2016-01-26 18:01:35 +08:00
; CHECK: polly.stmt.next:
ScopInfo: Never add read accesses for synthesizable values Before adding a MK_Value READ MemoryAccess, check whether the read is necessary or synthesizable. Synthesizable values are later generated by the SCEVExpander and therefore do not need to be transferred explicitly. This can happen because the check for synthesizability has presumbly been forgotten in the case where a phi's incoming value has been defined in a different statement. Differential Revision: http://reviews.llvm.org/D15687 llvm-svn: 258998
2016-01-28 06:51:56 +08:00
; CHECK-NEXT: store i32 2, i32* %phi.phiops
BlockGenerators: Replace getNewScalarValue with getNewValue Both functions implement the same functionality, with the difference that getNewScalarValue assumes that globals and out-of-scop scalars can be directly reused without loading them from their corresponding stack slot. This is correct for sequential code generation, but causes issues with outlining code e.g. for OpenMP code generation. getNewValue handles such cases correctly. Hence, we can replace getNewScalarValue with getNewValue. This is not only more future proof, but also eliminates a bunch of code. The only functionality that was available in getNewScalarValue that is lost is the on-demand creation of scalar values. However, this is not necessary any more as scalars are always loaded at the beginning of each basic block and will consequently always be available when scalar stores are generated. As this was not the case in older versions of Polly, it seems the on-demand loading is just some older code that has not yet been removed. Finally, generateScalarLoads also generated loads for values that are loop invariant, available in GlobalMap and which are preferred over the ones loaded in generateScalarLoads. Hence, we can just skip the code generation of such scalar values, avoiding the generation of dead code. Differential Revision: http://reviews.llvm.org/D16522 llvm-svn: 258799
2016-01-26 18:01:35 +08:00
; CHECK-NEXT: br label %polly.stmt.join
define i32 @func() {
entry:
br label %start
start:
br i1 true, label %loop, label %join
loop:
%i = phi i32 [ 0, %start ], [ %i.inc, %loop ]
%i.inc = add nsw i32 %i, 1
%cond = icmp slt i32 %i.inc, 2
br i1 %cond, label %loop, label %next
next:
br label %join
join:
%phi = phi i32 [%i.inc, %next], [0, %start]
br label %return
return:
ret i32 %phi
}