This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Ada subtypes and base types
- From: Jeffrey A Law <law at redhat dot com>
- To: Sebastian Pop <sebastian dot pop at cri dot ensmp dot fr>
- Cc: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>, gcc at gcc dot gnu dot org
- Date: Fri, 24 Feb 2006 11:15:42 -0700
- Subject: Re: Ada subtypes and base types
- References: <10602241616.AA08086@vlsi1.ultra.nyu.edu> <20060224174211.GA4315@napoca.cri.ensmp.fr>
- Reply-to: law at redhat dot com
On Fri, 2006-02-24 at 18:42 +0100, Sebastian Pop wrote:
> Richard Kenner wrote:
> > Just to make sure I've dotted the i's and crossed the t's, this is not
> > what's happening when we hang in VRP when compiling a-textio.
> >
> > We convert the incoming object from natural___XDLU_0___2147483647
> > into its base type, perform the addition in the base type, then
> > convert back to XDLU_0_2147483647.
> >
> > The above is exactly what I thought everybody agrees is and should be
> > happening, so I'm confused by your "this is not what's happening"
> > comment above.
>
> So if I understand correctly, if we can prove that the operation does
> not overflow in natural___XDLU_0___2147483647, then there is no need
> of a cast to the base type and back.
>
> chrec_convert is checking for non overflowing sequences before
> removing a cast, and that is missing from the aggressive convert.
> Aggressive convert has been intentionally implemented this way because
> the conservative chrec_convert has caused performance regressions (see
> sixtrack slowdowns from last August).
>
> A patch like the following would solve the problem too, but will
> introduce performance regressions... so I'm not sure that it is a good
> solution.
Another possibility is to simply not allow conversions between a
subtype and basetype. Again, that might not be as drastic as
your change.
jeff