[polly] r221393 - BlockGenerator: Recompute values from SCEV before handing back the original values

[Johannes Doerfert]

On 11/05, Tobias Grosser wrote:
> Author: grosser
> Date: Wed Nov  5 14:48:56 2014
> New Revision: 221393
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=221393&view=rev
> Log:
> BlockGenerator: Recompute values from SCEV before handing back the original values
> 
> This patch moves the SCEV based (re)generation of values before the checking for
> scop-constant terms. It enables us to provide SCEV based replacements, which
> are necessary to correctly generate OpenMP subfunctions when using the SCEV
> based code generation.
> 
> When recomputing a new value for a value used in the code of the original scop,
> we previously directly returned the same original value for all scop-constant
> expressions without even trying to regenerate these values using our SCEV
> expression. This is correct when the newly generated code remains fully in the
> same function, however in case we want to outline parts of the newly generated
> scop into subfunctions, this approach means we do not have any opportunity to
> update these values in the SCEV based code generation. (In the non-SCEV based
> code generation, we can provide such updates through the GlobalMap). To ensure
> we have this opportunity, we first try to regenerate scalar terms with our SCEV
> builder and will only return scop-constant expressions if SCEV based code
> generation was not possible.
Is this the only solution we have? It seems this might have compile time
effects as the early exits are moved. Does this work if the value used
in the subfunction is a induction variable of a loop in/outside of the
SCoP? I looked into this problem a bit myself and I am not certain this
is the best (or even a complete) way of handling the problem.

> This change should not affect the results of the existing code generation
> passes. It only impacts the upcoming OpenMP based code generation.
> 
> This commit also adds a test case. This test case passes before and after this
> commit. It was added to ensure test coverage for the changed code.
Whats the benefit here? As long as the code does not segfault it sounds
like the test is not really helpful or is it?

Best regards,
  Johannes

-- 

Johannes Doerfert
Researcher / PhD Student

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

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/20141106/5f8cdc51/attachment.sig>