This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] for PRs 27639 and 26719
- From: Ian Lance Taylor <iant at google dot com>
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: Eric Botcazou <ebotcazou at adacore dot com>, Richard Guenther <rguenther at suse dot de>, gcc-patches at gcc dot gnu dot org, sebastian dot pop at cri dot ensmp dot fr
- Date: 03 Jul 2006 21:20:36 -0700
- Subject: Re: [patch] for PRs 27639 and 26719
- References: <20060520192624.GA28713@atrey.karlin.mff.cuni.cz> <200606251403.53574.ebotcazou@adacore.com> <20060626212619.GA800@atrey.karlin.mff.cuni.cz> <200606270046.15998.ebotcazou@adacore.com> <20060626230656.GA24710@atrey.karlin.mff.cuni.cz> <20060628040144.GA6271@atrey.karlin.mff.cuni.cz>
Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> writes:
> > > I disagree: IVOPTs should preserve the semantics of subtypes, that is to say
> > > the arithmetics operations are performed in the base type and the result is
> > > casted to the subtype. IOW, it should not generate IVs in subtypes. IIUC
> > > it's Jeff's position too: http://gcc.gnu.org/ml/gcc/2006-02/msg00590.html
> >
> > OK, I was not aware of this (I was cced in the mail, but with a typo in
> > the address). I will prepare the patch to fix the problem.
>
> here is the patch I'd consider correct. I still need to test it (I
> forgot to include ada in regtesting this time).
I know you didn't submit this patch officially yet, but here are a few
comments.
> + /* Returns true if TYPE is a type in that we cannot directly perform
> + arithmetics, even though it is a scalar type. */
> +
> + static bool
> + nonarithmetic_type_p (tree type)
> + {
> + /* Ada frontend uses subtypes -- an arithmetic cannot be directly performed
> + in the subtype, but a base type must be used, and the result then can
> + be casted to the subtype. */
> + if (TREE_CODE (type) == INTEGER_TYPE && TREE_TYPE (type) != NULL_TREE)
> + return true;
> +
> + return false;
> + }
> +
I don't think the name is well chosen. The name implies that it tests
for a type which is not an arithmetic type, i.e., not a number. But
actually, of course, it tests for a type for which we implement
operations in a different type. How about a name like
integer_subtype_p?
The comments need a little work.
> + /* If we cannot really perform arithmetics in TYPE, avoid creating a scev
> + in this type. */
> + if (nonarithmetic_type_p (type))
> + return false;
/* If we cannot perform arithmetic in TYPE, avoid creating an scev. */
> + /* If we cannot really perform arithmetics in TYPE, avoid creating a scev
> + in this type. */
> + if (nonarithmetic_type_p (type))
> + return false;
Likewise.
This patch is preapproved with those changes, if testing and bootstrap
pass. Or please send another version.
Thanks.
Ian