Re: Compiling GCC with g++: a report

[DJ Delorie <dj@redhat.com>]

> Might it be more desirable for the compiler's code to only refer to
> target "type" modes as opposed to "size" modes?

Not always, see my mail about Pmode.  The problem isn't just how gcc
refers to machine words, but that gcc assumes their usage is context
independent or inflexible.  For example, assuming int_mode is the same
size as your general registers (esp when the target interface has a
way of asking how big hard regs actually are).

> Thereby avoiding the temptation to incorrectly assume that any
> particular "size" mode, like SImode corresponds to the targets int
> or int* mode for example?

I'd like to call my modes "FREDmode" and "WILMAmode" and the MI parts
shouldn't care at all.  Yes, I want to define addfredwilma3 MD
patterns.  If they need an "unsigned int" mode, they should ask the
target what "unsigned int" means (bits), and find a mode that matches
that description.  I'd like the MI to ask the target "I need to
multiply these types/modes together, what modes should I promote them
to, and what mode will the result be?"

I don't want to have to define a huge list of "mode types" when MI can
figure most of them out from a few BITS_PER_ defines, or from context.

> Thereby the compiler's code should only refer to "type" modes:

Don't type trees already have a machine_mode field?
I.e. TYPE_MODE(integer_type) ?  I know decls do.

The target already has a set of bits-per-type settings, we can look up
modes by size that way and assign them to tree TYPE nodes as needed.

The target would need a new set of hooks for things like "mode for
address of foo" or "mode of stack pointer" or "best mode for hard reg".

The rest of gcc should avoid looking up modes in general, so it's ok
for a lookup_integer_mode_by_bits() call to be expensive.  Instead,
the mode should be deduced (or copied) from the available operands.
Perhaps a fast mode_wider_expanded() lookup for expanding multiplies.