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
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
