This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] ipa bitwise constant propagation
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: kugan <kugan dot vivekanandarajah at linaro dot org>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Richard Biener <rguenther at suse dot de>, Prathamesh Kulkarni <prathamesh dot kulkarni at linaro dot org>, Martin Jambor <mjambor at suse dot cz>, gcc Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 5 Aug 2016 13:36:44 +0200
- Subject: Re: [RFC] ipa bitwise constant propagation
- Authentication-results: sourceware.org; auth=none
- References: <CAAgBjM=iB5xbu6FLuzRui4fsHnGRJSC-ZpHYmvFmrSD3Dy+hig@mail.gmail.com> <alpine.LSU.2.11.1608040928260.30444@t29.fhfr.qr> <20160804130549.GA77269@kam.mff.cuni.cz> <2ae790a8-c30b-bbcc-9d8d-db60f10f9d87@linaro.org>
> 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
>