On Mon, 17 Apr 2023, Richard Biener wrote: > On Fri, 14 Apr 2023, Hans-Peter Nilsson wrote: > > If after all, a change to the size of the code and mode > > bit-fields in rtx_def is necessary, like to still fit 64 bytes
(Sorry: 64 bits, not counting the union u.) > > such become non-byte sizes *and* that matters for compilation > > time, can that change please be made target-dependent? Not as > > in set by a target macro, but rather deduced from the number of > > modes defined by the target? > > > > After all, that number is readily available (or if there's an > > order problem seems likely to easily be made available to the > > rtx_def build-time definition (as opposed to a gen-* -time > > definition). > > But it gets us in the "wrong" direction with the goal of having > pluggable targets (aka a multi-target compiler)? But also away from the slippery slope of slowing down gcc compilation (building and running) while not adding any observable value. (Also, a unified gcc would be years in the future, and the proposal is easily removed.) > Anyway, I suggest we'll see how the space requirements work out. > We should definitely try hard to put the fields on a byte > boundary so accesses become at most a load + and. I'll be quiet until then. :) brgds, H-P
