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

Chris Lattner clattner at apple.com
Wed Apr 24 11:37:31 PDT 2013


On Apr 24, 2013, at 11:28 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote:
>> 
>> Because this is a canonicalization of this sort, it seems clearly good to do on IR, and early.  Doing something like this at the codegen level specifically for micro-architectural           reasons could also make sense, but I don't see that eliminating the usefulness of doing it early as well.
> Introducing a "select" at IR level dose not necessarily means CodeGen convert the "select" with predicated instruction like cmov.
> cmov is not necessary inexpensive, for example, on Pentium 4, the latency of cmov is about 10+ cycle. 

Yes, I truly understand that.  My point is that it is still a canonicalization: depending on how the user wrote the code is silly for the opposite reason: if they wrote code with ?: or max on pentium 4, codegen should convert it to an "if" if the branch is biased.

>>> That said, we should have a reason to if-convert before lowering other than optimizing for a machine's cpu pipeline.
>>> 
>>> Are we all convinced that if-converting a single store is the proper canonical form?
>> 
>> I am, at least in this specific benchmark's case.  You *can't* legally do the if conversion if you are introducing a memory access that otherwise would not have done.  Doing this can have lots of semantic effects.  In order for this to be *legal* at all (ignoring profitability) you have to prove that a subsequent store is happening to the memory location.
>> 
>> In this case, the *profitability* comes down to being able to obviously, locally, eliminate a load from the address.  It's true that GVN/PRE can eliminate part of the load in principle, but in practice this doesn't happen.
> GVN get rid of all the loads for the cases this if-cvt is trying to catch. 

… but much much later in the pipeline.  My point is that the transformation is still locally profitable.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130424/ac50667b/attachment.html>


More information about the llvm-commits mailing list