[PATCH] Infer known bits from dominating conditions

hfinkel at anl.gov hfinkel at anl.gov
Tue Mar 3 10:39:41 PST 2015


> To be clear, is this a request for me to evaluate this before submission?  I really don't see the need given that a) the current implementation is fast, and b) this is an experimental flag.


Yes, it is. My feeling is that this is not particularly complicated, and if it is, then there's something I'm not considering properly.

To be clear, this is a very important missing capability, and I want to make sure that we don't prematurely optimize here:  inconsistencies here will be *very* user visible, and I'm concerned that with your approach, small local code changes will cause drastic changes in the output by turning on and off this logic. If a more general approach is not feasible, then so be it, I'll take what we can get, but I want to make his decision quantitatively -- and I don't want to start with a design that will need to be rewritten to make forward progress.

> > Why do you care that the cmp has only one use? Why not look at all of the branches that use the cmp result?

>  We could, and may someday.  Doing so involves a potential increase in

>  compile time.  I'm deliberately going for minimal compile time impact,

>  even at the loss of some effectiveness.  I want to be able to turn this

>  on by default.  Most of my actual motivating cases are really simple.


Please measure this. Unless this is really needed, please take it out. Users can change codes to introduce extra uses of comparison results in many ways, and doing so should not change the optimizers ability to make use of the information.

> I would strongly prefer going with the fastest implementation now and

>  evaluating extensions at a later time.  If you think it matters and is

>  cheap enough, feel free to contribute a patch.  :)


But I don't know that it is the fastest implementation, or how much that matters. Fast matters, but it is not the only thing that matters. Using a DT walk with a cutoff might actually be faster. Stability of optimization results to small source changes is also really important. Consistency with other optimizer capabilities is also really important.

Let's work together on this. Yes, if you don't want to do this, I'll get to it in a couple of months.


http://reviews.llvm.org/D7708

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






More information about the llvm-commits mailing list