[PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2b

[Michael Meissner]

On Wed, Oct 03, 2012 at 09:42:05PM -0400, David Edelsohn wrote:
> @@ -1115,7 +1118,8 @@ static const struct attribute_spec rs600
>    { NULL,        0, 0, false, false, false, NULL, false }
>  };
>  
> -#ifndef MASK_STRICT_ALIGN
> +#ifndef OPTION_MASK_STRICT_ALIGN
> +#define OPTION_MASK_STRICT_ALIGN 0
>  #define MASK_STRICT_ALIGN 0
>  #endif
>  #ifndef TARGET_PROFILE_KERNEL
> 
> Why does this fragment define OPTION_MASK_STRICT_ALIGN but does not
> remove definition of MASK_STRICT_ALIGN?
> 
> Similarly for
> 
> -#ifndef MASK_64BIT
> +#ifndef OPTION_MASK_64BIT
> +#define OPTION_MASK_64BIT 0
>  #define MASK_64BIT 0
>  #endif
> 
> Why define both OPTION_MASK_64BIT and MASK_64BIT?

Most of these changes are due to the way the opt*.awk generate options.h and
options.c.

For instance, if the rs6000.opt has:

	maltivec
	Target Report Mask(ALTIVEC) Save
	Use AltiVec instructions

The opt* will generate:

	#define MASK_ALTIVEC (1 << 1)
	#define TARGET_ALTIVEC ((target_flags & MASK_ALTIVEC) != 0)

If however, you use a Var() to use a different variable, such as:

	maltivec
	Target Report Mask(ALTIVEC) Var(rs6000_isa_flags)
	Use AltiVec instructions

the opt*.awk will generate:

	#define OPTION_MASK_ALTIVEC (HOST_WIDE_INT_1 << 1)
	#define OPTION_ALTIVEC ((rs6000_isa_flags & OPTION_MASK_ALTIVEC) != 0)

> +/* Map OPTION_<xxx> back into TARGET_<xxx> options in rs6000_isa_flags.  */
> 
> Why set up correspondence for all OPTION_xxx flags back to TARGET_xxx flags?

The defines of TARGET_<xxx> and MASK_<xxx> are meant to reduce the amount of
code that is changed.

I have a new set of patches that drops back and doesn't change the existing
flags, and just defines a 2nd flags word that I will post in a separate
message.

-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meissner@linux.vnet.ibm.com	fax +1 (978) 399-6899