[PATCH] D13611: [Polly] Create virtual independent blocks

[Johannes Doerfert via llvm-commits]

jdoerfert added a comment.

In http://reviews.llvm.org/D13611#268449, @grosser wrote:

> Hi Johannes,
>
> great to see we will finally get rid of the IndependentBlocks pass. I just had a very first skim over this patch, but did not manage to do a full review yet.
>
> The two main items I would still like to look into:
>
> 1. This seems to conflict with http://reviews.llvm.org/D12975 (Michael's DE-LICM)
>
>   I need to get a better understanding in which ways these patches possibly conflict (as well as the overall design).


Yeah, at the time this was written it was fine but __as far as I understand it__ the MAPPED accesses (and possibly more) implicitly change the semantics of the SCoP description without it beeing actually changed (except the "MAPPED" flag). One could argue that this should look for MAPPED accesses but I don't, instead I will argue that "MAPPED" should __not__ be an access property that is determined on the CFG and only a flag in the access description that turns on some alternate path in the code generation. An access that is not actually happening (no code is generated for) should not be in the SCoP description and the ones in there should happen where they are and read/write the location they define. If that is the case this patch should work properly.

> 2. Post-processing statements vs. instruction-list ScopStmts

> 

>   Your current approach of first building all ScopStmts and then post-process them to eliminate scalar dependences is interesting. However, it requires a special post-processing phase in ScopInfo and additional special-purpose code in ScopStmt and BlockGenerator. I wonder if it may make sense to build ScopStmts from the beginning just as a list of instructions (instead of a basic block) which could then be uniformly processed in the BlockGenerator.


Processing the SCoP allows general solutions which are not (easily) reproduceable on the CFG, e.g., determining if a load is overwritten is easy and precise but hard on the CFG. The instruction list is a different issue and it would remove not that much code/logic anyway. With the pending patches by Michael we will reload scalars at the beginning of a statmeent and as I pointed out on that review, alsmost the same is added here. While I did not get a valuable response on the idea (and implementation sketch) to merge the recomputation and the scalar reload at the beginning of a statement, I think it is what we ultimately want.


http://reviews.llvm.org/D13611