[llvm] r179957 - SimplifyCFG: If convert single conditional stores

[Arnold]

Hi Chandler,

I totally agree with you that if we can model the effects (issue slots) and predict the performance we should do it in machine if-conversation. 

In this case - I am not sure we can.

Assume we are in a loop and assume we have two issue slots for memory ops- but it really does not matter how many we choose - we going to end up deciding not to do it -  because we are going to take up two cycles of the two load/store unit instead of one([first store/may alias load][second speculated store]). But you may want to still do it - heuristically speaking because of the cost of the mid predict so I am not sure a "better" decision could be made. (On your typical architecture)
Given that there are potential positive secondary effects of having longer basic blocks I believe the overall effect to be positive.

Also I believe in the short term the machine if conversation pass is not in the shape to be turned on and this opt temporarily improves things until it can (possibly) be superceeded by machine if conversation. 

I just don't want to look bad on phoronix if only temporary.  ;)


Best,
Arnold
(Having said all that I will happily revert the patch if folks disagree I would have just liked to see it go through some bots)

Sent from my iPhone

 On Apr 20, 2013, at 4:56 PM, Chandler Carruth <chandlerc at google.com> wrote:

> On Sat, Apr 20, 2013 at 10:42 PM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote:
>> SimplifyCFG: If convert single conditional stores
> 
> Last time I touched if-conversion in simplifycfg, Evan, Jakob, and Andy had serious objections to it, and insisted that it should instead be done by enabling a (sufficiently conservative) version of the early if conversion in the backend.
> 
> I'm actually sympathetic to the desire to do this (i hit similar performance problems as the one you're seeing, specifically in zlib in my case), but I really see their point. Either way, it seems quite strange to reverse direction without some commentary about previous attempts, alternatives, and what the plan is for getting the x86 backend to handle if-conversion in a sane way[1].
> 
> 
> [1]: And unless there is any confusion, I think we all agreed that the sane form of if-conversion on x86 is *insanely* conservative due to the relative efficiency of predicted branches and cost of speculation. It's conversions much like the one you're targeting where the store itself is the only speculation and it is already in cache are the best kinds.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130420/8e67cee6/attachment.html>