[PATCH] Infer known bits from dominating conditions

[Hal Finkel]

----- Original Message -----
> From: "Philip Reames" <listmail at philipreames.com>
> To: reviews+D7708+public+73801db3d9f7f7c4 at reviews.llvm.org, nlewycky at google.com, hfinkel at anl.gov
> Cc: sanjoy at playingwithpointers.com, llvm-commits at cs.uiuc.edu
> Sent: Thursday, March 5, 2015 1:05:59 AM
> Subject: Re: [PATCH] Infer known bits from dominating conditions
> 
> On 03/04/2015 08:29 AM, hfinkel at anl.gov wrote:
> > In http://reviews.llvm.org/D7708#134110, @reames wrote:
> >
> >> Hal - preliminary numbers on the dominance based approach make it
> >> look like that might be viable.  I need to cleanup my hacked
> >> implementation and fix at least one bug, but my initial
> >> impression is that it appears to be fast enough.  I'm a bit
> >> surprised by this, but it's what the data says.
> >>
> >> Worth discussing is whether we should actually incorporate both.
> >>  They seem to be good at different cases and maybe we should
> >> exploit that.  The use based approach is good for grabbing facts
> >> far from the use site (i.e. function entry guards), while the
> >> dominance approach is likely more powerful since it's not
> >> restricted to direct uses, but is probably best limited to a
> >> local scope.  Thoughts?
> >
> > Yes, perhaps with a FIXME if there is some other "right" way to fix
> > the problem.
> Ok, I'll try to get a merged patch up for review tomorrow.  This is
> coming out of my spare time right now, so it might take a day or two.

Sure; thanks again for working on this.

> 
> > I've been thinking of something like LVI that keeps track of known
> > bits. What do you think?
> I've had thoughts in similar direction, but I think it would really
> needs to be merged with ValueTracking.  We'd want instcombine to
> exploit
> it and instcombine uses ValueTracking.  Teaching instcombine about
> two
> analyzes that don't cross feed seems less than ideal.
> 
> I've mentioned the idea of turning VT into an analysis pass to
> Chandler
> previously.  He had serious reservations about that.  If I remember
> correctly, he was much less concerned about introducing an internal
> cache inside VT.  He was mostly concerned about invalidation bugs.
>  He
> believes that much of instcombine assumes VT works from first
> principals
> and that changing that would be *hard*.

I'm not sure that this is true, but let's discuss this in some other thread.

> 
> I also see this as being orthogonal to the original patch.  That was
> about catching any dominating conditions at all.  This would be about
> making VT better as a whole, not just specific to dominating
> conditions.

Yes, I did not mean to imply otherwise.

> 
> p.s. The other orthogonal work here is propagating conditional
> constants
> early in the optimizer.  (possibly instcombine?)  If you have
> thoughts
> here, let's me know.

Will do.

 -Hal

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

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory