Re: Reorganise machmode.h headers

[Richard Sandiford <rdsandiford@googlemail.com>]

Jeff Law <law@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.sandiford@arm.com>
>> 	    Alan Hayward  <alan.hayward@arm.com>
>> 	    David Sherwood  <david.sherwood@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