This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] for PRs 27639 and 26719


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]