This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, PR 50744] Prevent overflows in IPA-CP
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Jan Hubicka <hubicka at ucw dot cz>
- Date: Thu, 1 Dec 2011 17:16:21 +0100
- Subject: Re: [PATCH, PR 50744] Prevent overflows in IPA-CP
- References: <20111118174752.GA1950@virgil.arch.suse.de> <CAFiYyc2AXjt0Q68JgS9_-Gp28YfMkZbj9U=W7vrxwGHkjmsYGA@mail.gmail.com>
> On Fri, Nov 18, 2011 at 6:47 PM, Martin Jambor <mjambor@suse.cz> wrote:
> > Hi,
> >
> > PR 50744 is an issue with an integer overflow when we propagate the
> > estimated size and time effects from callees to callers. ?Because such
> > paths in the parameter value graph can be arbitrarily long, we simply
> > need to introduce an artificial cap on these values. ?This is what the
> > patch below does. ?The cap should be more than enough for any
> > reasonable values.
> >
> > Moreover, I have looked at how we then process the accumulated
> > estimates and decided to compute evaluation ratio in
> > good_cloning_opportunity_p in HOST_WIDEST_INT. ?Call graph frequencies
> > are numerators of fractions with denominator 1000 and therefore
> > capping the size and cost estimate as well as the frequency sums so
> > that their multiplication would not overflow an int seems too
> > constraining on 32bit hosts.
> >
> > Bootstrapped and tested on x86_64-linux without any problems, OK for
> > trunk?
>
> This introduces host-dependent code generation differences, right?
> You can simply use int64_t for code that is run on the host only.
Well, if we rely on int64_t being around now (that is probably the case with
C++ switch), HOST_WIDEST_INT is always equivalent, isn't it?
Honza