[PATCH] Allow PRE to duplicate loads in LICM like loop case

Daniel Berlin dberlin at dberlin.org
Sun Jan 25 10:31:16 PST 2015


I'm also generally fine with this, if we are fine with destroying later if
 we rewrite this all :)


On Sun Jan 25 2015 at 7:29:28 AM hfinkel at anl.gov <hfinkel at anl.gov> wrote:

> Generally speaking, I'm in favor of this. We only loose in the case where
> the loop trip count is (very) small and the additional load is on a
> relatively-hot path through the loop. However, I think we can use BPI to
> filter out such cases.
>
> > It's worth mentioning that the 'merge block' concept is essentially a
> specialized form of jump threading. In fact, running '-jump-threading' does
> help in the loop cases I've looked at. However, running jump threading also
> inhibits some optimizations currently performed by LoadPRE. If we have a
> merge point where both inputs are unavailable, PRE will currently insert a
> single load at the merge. Running jump threading breaks this. Keeping that
> case working as it does today is why we only look through merge blocks with
> a single unavailable predeccesor in the patch.
>
>
> As a side comment, do we have a regression test covering this behavior? I
> believe this is a case where it is appropriate to have a regression test
> that runs opt -O3 (to get the default optimization pipeline), to make sure
> we don't disturb this current behavior. If we don't, can you please add one?
>
>
> ================
> Comment at: lib/Transforms/Scalar/GVN.cpp:1524
> @@ +1523,3 @@
> +/// reload)
> +static bool isLICMLike(BasicBlock* Header,
> +                       SmallVector<BasicBlock *, 4>& PredBlocks,
> ----------------
> Thoughts on whether or not it is worthwhile to use getAnalysisIfAvailable<LoopInfo>
> for this kind of thing instead?
>
> http://reviews.llvm.org/D7061
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150125/e8d502ca/attachment.html>


More information about the llvm-commits mailing list