Re: new __builtin_choose_type (patch) (new builtin_equal_types patch)

[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: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
> > To: mrs@windriver.com
> > Cc: gcc@gcc.gnu.org
> 
> >     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
double d;
float f;
__builtin_modes_equal_p (f, d) should be false,
__builtin_modes_equal_p ((double) f, d) should be true,
int i;
char c;
__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.

	Jakub