cris: don't define MAX_FIXED_MODE_SIZE

It's been 32 ever since the CRIS port was committed.
A TODO-item of mine has been to check whether the
non-default setting of MAX_FIXED_MODE_SIZE makes sense
wrt. performance and/or code-size with a modern gcc.  It
doesn't, so it goes.  The setting is now the default,
GET_MODE_BITSIZE (DImode) (defaults.h) i.e. 64.

Measurements at r11-7500 (f3641ac70eb0) on coremark with
"-O2 -march=v10 -mno-mul-bug-workaround" shows 0.04%
performance improvement with this change, and by inspection
the effect is that unused and/or unneeded stack-frames are
eliminated more often in the floating-point library (not in
the coremark main loop, thus the marginal improvement).  The
floating-point library is full of 64-bit unions used to pick
apart floating point numbers, so this kind of makes sense.

Inspection of a simulator trace shows that this is indeed
the only effect in coremark.  Other local micro-benchmarks
agree as to the net effect (no traces were inspected
though), and the most floating-point-heavy test shows an 8%
improvement.  These effects are of course subject to gcc
core tweaks and may make sense to be adjusted again in a
future release.

While MAX_FIXED_MODE_SIZE is IMO supposed to be an optional
macro for performance, setting it to anything smaller than
twice the size of an address exposes bad decisions in gcc
middle end, sometimes leading to internal compiler errors.
(It being set to 32 should *not* affect use of DImode as an
integer mode; it's for "integer machine modes of this size
or smaller can be used for structures and unions with the
appropriate sizes".)  Thus, with the default 64 instead of
32, there are two tests that now pass for the first time:
gcc.dg/attr-vector_size.c and gcc.dg/tree-ssa/pr93121-1.c.

gcc:
	* config/cris/cris.h (MAX_FIXED_MODE_SIZE): Don't define.

0 files changed, 0 insertions, 0 deletions