This is the mail archive of the
mailing list for the GCC project.
Re: new __builtin_choose_type (patch) (new builtin_equal_types patch)
- To: mike stump <mrs at windriver dot com>
- Subject: Re: new __builtin_choose_type (patch) (new builtin_equal_types patch)
- From: Jakub Jelinek <jakub at redhat dot com>
- Date: Fri, 5 Oct 2001 12:03:18 +0200
- Cc: kenner at vlsi1 dot ultra dot nyu dot edu, gcc at gcc dot gnu dot org
- References: <200110050233.TAA09893@kankakee.wrs.com>
- Reply-To: Jakub Jelinek <jakub at redhat dot com>
On Thu, Oct 04, 2001 at 07:33:13PM -0700, mike stump wrote:
> > Date: Thu, 4 Oct 01 22:25:34 EDT
> > From: email@example.com (Richard Kenner)
> > To: firstname.lastname@example.org
> > Cc: email@example.com
> > In a frontend, we never play with modes... The type can be found in
> > TREE_TYPE, and you should just use it. This is frontend code.
> > Mostly, but not totally, true. When stripping NOPs to look for
> > things, it's not uncommon for frontends to only strip NOPs that
> > don't change the mode.
> Sure, but you're going into way too much detail here. I'd just add,
> just in case people don't see the difference, bool != int, from a type
> system perspective, it doesn't matter if they both are 32 bits.
> Comparing modes can have them be the same. Comparing types, they
> never are, well, cept maybe in C when you use a typedef.
Maybe both kinds of type comparisons are useful, so perhaps we could have
__builtin_types_equal_p (x, y) which would return non-zero if
TYPE_MAIN_VARIANTs are the same and __builtin_modes_equal_p (x, y) which
would return non-zero if the TYPE_MODEs are the same. I guess the latter
would be what altivec would like to use (and probably tgmath.h as well).
BTW: stripping NOPs is problematic here, because I think
__builtin_modes_equal_p (f, d) should be false,
__builtin_modes_equal_p ((double) f, d) should be true,
__builtin_modes_equal_p (i, c) should be false,
__builtin_modes_equal_p (i, (int) c) should be true. The code has to
differentiate between NOPs added by the compiler because of argument
promotions and explicit casts.