On Thu, 12 Apr 2007, H. J. Lu wrote:
> On Thu, Apr 12, 2007 at 07:03:34PM +0000, Joseph S. Myers wrote:
> > On Thu, 12 Apr 2007, H. J. Lu wrote:
> >
> > > Are there any documents/examples for a second variable for flag bits?
> >
> > config/linux.opt uses Mask and InverseMask with Var.
>
> i386.c has many
>
> static const struct builtin_description bdesc_comi[] =
> {
> { MASK_SSE, CODE_FOR_sse_comi, ....
>
> Whatever approach we choose, it won't be small. It seems to me
> that bitfield is less error prone.
Conversion to bit-fields seems pretty error-prone to me. Consider for
example the large CPU table in rs6000.c with entries like:
{"440", PROCESSOR_PPC440,
POWERPC_BASE_MASK | MASK_SOFT_FLOAT | MASK_MULHW | MASK_DLMZB},
How do you propose to convert such MASK|MASK to bit-fields? The natural
approach would be to have a structure containing the bit-fields in the
table and use C99 designated initializers, but we can't do that.
I suspect you'll end up needing a generator program that takes CPU tables
and constructs initializers for bit-fields. (A common format for CPU
tables does have other advantages, such as --help being able to list the
supported CPUs.) And every reference to masks, across every target, needs
updating - or do you propose *yet another* incomplete transition by
changing only one target?
It will be necessary to benchmark for any performance differences between
masks and bit-fields. (GCC should coalesce accesses to multiple
bit-fields into mask operations - the question is whether in practice it
does so in all relevant cases.)
--
Joseph S. Myers
[EMAIL PROTECTED]
