> Hi Honza, > > On 04/08/16 23:05, Jan Hubicka wrote: > >>I didn't look at the propagation part but eventually the IPA-CP > >>lattice gets quite big. Also the alignment lattice is very > >>similar to the bits lattice so why not merge those two? But > > > >This was always the original idea to replace alignment propagation by bitwise > >ccp. I suppose we only have issue here because nonzero bits are not tracked > >for > >pointers so we need to feed the original lattices by hand? > > I also raised this one with Prathamesh off line. With the early-vrp, > we should have nonzero_bits for non pointers. For pointers we should > feed the lattices with get_pointer_alignment_1 as it is done in > ipa-cpalignment propagation.
Yes, that is the general idea. Note that also for pointers it would be very useful to track what pointers are non-NULL (C++ multiple inheritance inserts a lot of NULL pointer checks that confuse us in later analysis and it would be nice to optimize them out). I am not very convinced saving a pointer is worth to make difference between pointers/nonpointers for all the local tracking. > > >We could also make use of VR ranges and bits while evaultaing predicates > >in ipa-inline-analysis. I can look into it after returning from Leeds. > > Indeed. With ealrly dom based VRP (non iterative at this point), > some of the ranges can be pessimistic and can impact the estimation. > Let me have a look at this. Yes, but those are independent issues - size/time estimates should take into account the new info we have and we should work on getting it better when we can ;) I will try to revisit the size/time code after returning from my vacation and turn it into sreals for time + cleanup/generalize the APIs a bit. I tried to do it last stage1 but got stuck on some of ugly side cases + gengtype not liking sreal type. Honza > > Thanks, > Kugan >
