> 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.
