> where then the target may declare class machine_mode
> target_int_mode ("HI", 16),
This is where we disagree. The *target* shouldn't map types to modes.
The *MI* should map types to modes. The target just creates the modes
it supports and describes them. The MI looks them up by description
(NOT NAME). If the MI needs a 32 bit unsigned scalar, it does
lookup_mode(32, M_SCALAR, M_UNSIGNED) and uses whatever gets returned.
The fact that you're still trying to assign a "well known name" to a
given type/mode/whatever means you haven't gotten away from the (to
me) fundamental problem, that MI chooses modes according to what
they're *for* instead of according to what they *are*.
> target_unit_mode // presumably the target's smallest addressable datum.
BImode in most cases, not really useful that way.
> target_word_mode // presumably the target's largest addressable datum.
BLKmode in all cases. Also not useful.
> as there seems no valid reason for the target neutral portion of the
> compiler to ever refer to XXmode under any circumstance?
Ah, but in your case it *is* aware, it just calls it
"target_word_mode" instead of "SImode" with all the same problems with
assumptions.
> where correspondingly the MI portions of GCC utilizes the appropriate
> pointer mode as a function of the type of access being performed,
In my case, the target has to check the attributes of the
function/data to decide what kind of pointer to use. Again, "MI
assuming" that all function pointers are the same is WRONG.
> - understood, although I honestly don't believe there are that many, and
> it eliminates any possible confusion, and a host of other #defines.
My current port supports maybe 4-5 hard modes. There are 19
machine_modes defined. That's about 4x as many as I really need to
define, and that doesn't even include synthetic vector modes and such.
> - as you've noted, all the information GCC MI portion needs to "do the
> right thing" already exists scattered in various target definitions,
> but it hasn't prevented mode assumptions from being made, and XXmodes
> being hard-coded into the MI sources on occasion; which is the only
> reason that I thought that by forcing target_TYPE_mode's to be the
> only thing available, GCC would indirectly be forced to always to the
> "right thing"?
The less available the better, true. But target_*_modes don't need to
be available either. If you use a query/lookup API, MI can assume
there are a *lot* of machine modes (one for each variable, one for
each function, one for each C data type, etc), and let the target map
them to available modes.
targetm.modes.set_mode_for_decl(decl);
See? This allows for a custom mode just for the given decl (it might
be a 17 bit ternary value in a DSP), doesn't make assumptions about
available machine modes, and MI can provide a naive default hook for
targets that do "the usual thing".
if (!TYPE_MODE (TREE_TYPE (decl)))
TYPE_MODE (TREE_TYPE (decl)) = find_mode_for_type (TREE_TYPE (decl));
DECL_MODE (decl) = TYPE_MODE (TREE_TYPE (decl));
or something like that. Caching is OK if you cache it the right way
(with a type, not in a global "this is a pointer" variable).
