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

[hfinkel at anl.gov]

In http://reviews.llvm.org/D7061#116088, @reames wrote:

> In http://reviews.llvm.org/D7061#113287, @hfinkel 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.
>
>
> I agree we can, but should we?  You might still be able to simplify the other path through the loop.  It's not clearly profitable, but it's also not clearly not profitable either.
>
> I'm open to implementing the BFI based filter if you want to see it.


I would really like to see it. --  It may yet turn out not to be practical, but I'd like the experiment to be performed.

> 

> 

> > 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?

> 

> 

> I'm not sure if we have the O3 test, but we do have tests for GVN/PRE which would break if the jump threading behavior were integrated into GVN.  I think that's actually what we want.  I really suspect the current need for redundant merge points is just papering over deficiencies in the PRE code.  In fact, there's a FIXME that says exactly that.  :)

> 

> Also, writing an O3 test for this would be very hard.  You'd need to construct it in a way where no pass can destroy the redundant control flow, but it's exposed to jump threading.  This seems way too fragile to be worthwhile.


Okay, fair enough.


http://reviews.llvm.org/D7061

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/