[Richard,Sandiford] Add an array_mode_supported_p target hook

This patch adds an array_mode_supported_p hook, which says whether
MAX_FIXED_MODE_SIZE should be ignored for a given type of array.
It follows on from the discussion here:

    http://gcc.gnu.org/ml/gcc/2011-03/msg00342.html

The intended use of the hook is to allow small arrays of vectors
to have a non-BLK mode, and hence to be stored in rtl registers.
These arrays are used both in the ARM arm_neon.h API and in the
optabs proposed in:

    http://gcc.gnu.org/ml/gcc/2011-03/msg00322.html

The tail end of the thread was about the definition of TYPE_MODE:

#define TYPE_MODE(NODE) \
  (TREE_CODE (TYPE_CHECK (NODE)) == VECTOR_TYPE \
   ? vector_type_mode (NODE) : (NODE)->type.mode)

with this outcome:

    http://gcc.gnu.org/ml/gcc/2011-03/msg00470.html

To summarise my take on it:

- The current definition of TYPE_MODE isn't sufficient even for vector
  modes and vector_mode_supported_p, because non-vector types can have
  vector modes.

- We should no longer treat types as having one mode everywhere.
  We should instead replace TYPE_MODE with a function that takes
  a context.  Tests of things like vector_mode_supported_p would
  move from layout_type to this new function.

I think this patch fits within that scheme.  array_mode_supported_p
would be treated in the same way as vector_mode_supported_p.

I realise the ideal would be to get rid of TYPE_MODE first.
But that's going to be a longer-term thing.  Now that there's
at least a plan, I'd like to press ahead with the array stuff
on the basis that

(a) although the new hook won't work with the "target" attribute,
    our current mode handling doesn't work in just the same way.

(b) the new hook doesn't interfere with the plan.

(c) getting good code from the intrinsics (and support for these
    instructions in the vectoriser) is going to be much more important
    to most ARM users than the ability to turn Neon on and off for
    individual functions in a TU.

To give an example of the difference, the Neon code posted here:

    http://hilbert-space.de/?p=22

produces this inner loop before the patch (but with
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01996.html applied):

.L3:
	vld3.8	{d16-d18}, [r1]!
	vstmia	ip, {d16-d18}
	fldd	d19, [sp, #24]
	adr	r5, .L6
	ldmia	r5, {r4-r5}
	fldd	d16, [sp, #32]
	vmov	d18, r4, r5  @ v8qi
	vmull.u8	q9, d19, d18
	adr	r5, .L6+8
	ldmia	r5, {r4-r5}
	vmov	d17, r4, r5  @ v8qi
	vstmia	sp, {d18-d19}
	vmlal.u8	q9, d16, d17
	fldd	d16, [sp, #40]
	adr	r5, .L6+16
	ldmia	r5, {r4-r5}
	vmov	d17, r4, r5  @ v8qi
	vmlal.u8	q9, d16, d17
	add	r3, r3, #1
	vshrn.i16	d16, q9, #8
	cmp	r3, r2
	vst1.8	{d16}, [r0]!
	bne	.L3

With both patches applied, the inner loop is:

.L3:
	vld3.8	{d18-d20}, [r1]!
	vmull.u8	q8, d18, d21
	vmlal.u8	q8, d19, d22
	vmlal.u8	q8, d20, d23
	add	r3, r3, #1
	vshrn.i16	d16, q8, #8
	cmp	r3, r2
	vst1.8	{d16}, [r0]!
	bne	.L3

Tested on arm-linux-gnueabi.  OK to install?

Richard

gcc/
	* hooks.h (hook_bool_mode_uhwi_false): Declare.
	* hooks.c (hook_bool_mode_uhwi_false): New function.
	* target.def (array_mode_supported_p): New hook.
	* doc/tm.texi.in (TARGET_ARRAY_MODE_SUPPORTED_P): Add @hook.
	* doc/tm.texi: Regenerate.
	* stor-layout.c (mode_for_array): New function.
	(layout_type): Use it.
	* config/arm/arm.c (arm_array_mode_supported_p): New function.
	(TARGET_ARRAY_MODE_SUPPORTED_P): Define.

[Richard,Sandiford] Add an array_mode_supported_p target hook

Commit Message

Patch