Jeff Law <l...@redhat.com> writes: > On 11/16/2016 09:32 AM, Richard Sandiford wrote: >> Later patches will make machmode.h rely on wide-int.h and the >> new poly-int.h, so it needs to appear later in the coretypes.h >> include list. >> >> Previously machmode.h included insn-modes.h, which as well as >> the main mode enum contains configuration information like >> MAX_BITSIZE_MODE_ANY_INT. This still needs to come first, >> since files like wide-int.h depend on the configuration >> information. >> >> Similarly, later patches will make the auto-generated inline >> mode size functions use poly-int.h, so the patch splits them >> out into their own header file and includes it after the >> integer utilities. >> >> The patch also makes the generator files include machmode.h >> via coretypes.h. Previously they did it by more indirect means. >> >> Finally, the patch makes wide-int-print.h available via coretypes.h >> too. There didn't seem to be any reason to force only the print >> routines to be included directly, and it would be painful to extend >> that approach to the new polynomial integer classes. >> >> Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install? >> >> Thanks, >> Richard >> >> >> [ This patch is part of the SVE series posted here: >> https://gcc.gnu.org/ml/gcc/2016-11/msg00030.html ] >> >> gcc/ >> 2016-11-16 Richard Sandiford <richard.sandif...@arm.com> >> Alan Hayward <alan.hayw...@arm.com> >> David Sherwood <david.sherw...@arm.com> >> >> * Makefile.in (MACHMODE_H): Remove insn-modes.h >> (CORETYPES_H): New define. >> (MOSTLYCLEANFILES): Add insn-modes-inline.h. >> (insn-modes-inline.h, s-modes-inline-h): New rules. >> (generated_files): Add insn-modes-inline.h. >> (RTL_BASE_H, TREE_CORE_H): Use CORETYPES_H instead of coretypes.h. >> (build/gensupport.o, build/print-rtl.o, build/read-md.o): Likewise. >> (build/read-rtl.o, build/rtl.o, build/vec.o, build/hash-table.o) >> (build/inchash.o, build/gencondmd.o, build/genattr.o): Likewise. >> (build/genattr-common.o, build/genattrtab.o, build/genautomata.o) >> (build/gencheck.o, build/gencodes.o, build/genconditions.o): Likewise. >> (build/genconfig.o, build/genconstants.o, build/genemit.o): Likewise. >> (build/genenums.o, build/genextract.o, build/genflags.o): Likewise. >> (build/gentarget-def.o, build/genmddeps.o, build/genopinit.o) >> (build/genoutput.o, build/genpeep.o, build/genpreds.o): Likewise. >> (build/genrecog.o, build/genmddump.o, build/genmatch.o): Likewise. >> (build/gencfn-macros.o, build/gcov-iov.o): Likewise. >> * coretypes.h: Include everything up to real.h for generators. >> Include insn-modes.h first. Include wide-int-print.h after >> wide-int.h. Include insn-modes-inline.h and then machmode.h. >> * machmode.h: Don't include insn-modes.h here. >> * function-tests.c: Remove includes of signop.h, machmode.h, >> double-int.h and wide-int.h. >> * rtl.h: Likewise. >> * gcc-rich-location.c: Remove includes of machmode.h, double-int.h >> and wide-int.h. >> * optc-save-gen.awk: Likewise. >> * gencheck.c (BITS_PER_UNIT): Delete dummy definition. >> * godump.c: Remove include of wide-int-print.h. >> * pretty-print.h: Likewise. >> * wide-int-print.cc: Likewise. >> * wide-int.cc: Likewise. >> * hash-map-tests.c: Remove include of signop.h. >> * hash-set-tests.c: Likewise. >> * rtl-tests.c: Likewise. >> * mkconfig.sh: Remove include of machmode.h. >> * genmodes.c (emit_insn_modes_h): Split emission of inline functions >> into... >> (emit_insn_modes_inline_h): ...this new function. Emit the code >> into an insn-modes-inline.h header file, adding appropriate >> include guards and end comments. >> (emit_insn_modes_c_header): Remove include of machmode.h. >> (emit_min_insn_modes_c_header): Include coretypes.h rather than >> machmode.h. >> (main): Handle -i flag and call emit_insn_modes_inline_h when >> it is passed. > So I don't see anything here particularly problematical. My question is > whether or not there's anything significant to be gained to moving > forward with this kit, assuming the 67 piece kit is not likely to move > forward.
Yeah, I agree it's not worth it now that those patches won't go in. > I do think you'll need some tweaks to the contrib/header-tools which > know about the core headers and dependencies. Hopefully what's in there > is easy enough to figure out how to twiddle appropriately. Thanks for the pointer, will make a note to look at that for GCC 8. Richard
