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? Uros.
