On Mon, Oct 15, 2018 at 05:57:18PM +0200, Uros Bizjak wrote:
> On Mon, Oct 15, 2018 at 5:49 PM Uros Bizjak <ubiz...@gmail.com> wrote:
>
> > > Plus, I wonder if we shouldn't make it harder to run into these issues, by
> > > changing
> > > Target Report Mask(ISA_AVX5124FMAPS) Var(ix86_isa_flags2) Save
> > > etc. to
> > > Target Report Mask(ISA2_AVX5124FMAPS) Var(ix86_isa_flags2) Save
> > > so that we'll have OPTION_MASK_ISA2_AVX5124FMAPS macros instead of
> > > OPTION_MASK_ISA_AVX5124FMAPS and adjust all i386-common.c etc. uses from
> > > ISA
> > > to ISA2 for the ix86_isa_flags2 options. Perhaps we could have
> > > #define TARGET_ISA_AVX5124FMAPS TARGET_ISA2_AVX5124FMAPS
> > > compatibility macro, because unlike the OPTION_MASK_* and TARGET_*_P
> > > macros
> > > where you need to specify the right flags the TARGET_* macros already have
> > > that in implicitly. Uros, thoughts on this?
> >
> > I was looking for a mail, where we discussed x86_isa_flags2 as a
> > temporary solution, with the expectation that some other extensible
> > mechanism gets invented to handle ISA flags. Now we are in c++, and I
> > guess there should be more elegant way to deal with the issue.
>
> Maybe wide-int-bitmask.h can be used here, similar to how PTA_*
> defines are handled in i386.h?
Maybe, though I'm worried a lot about compile time performance,
we use TARGET_* macros everywhere.
Jakub
