> - ok, and how does it know that it needs a 32-bit unsigned scalar?
tm.h: #define INT_TYPE_SIZE 32
Combined with "unsigned int foo;" in the user's source file.
The MI doesn't need to know that this fits in a QImode.
> the world is it desirable to go go in a big circle to identify
> which mode corresponds to a type as defined by the target, rather
> than simply having the target define it directly?)
Because on many targets, small scalars can be held in larger
registers, and large scalars (or complex or vector types) can be held
in groups of small registers. There isn't a strict mapping between C
types and hardware modes. Plus, the target might provide attributes
that alter the mode (think "__attribute__((mode(FRED)))").
> correspondingly "well known named" types (such as bool, char, int,
In this case, the "well known named" things are front-end types, like
"int" and "short", not back-end types, like PSImode or V4QImode.
A simple example of this type of problem is when MI uses "SImode" for
integers, on a target with 16-bit integers. SImode is wrong. Any
time you have "well known" types coming from the *target* you're
setting yourself up for this type of thing.
> > BImode in most cases, not really useful that way.
>
> - maybe we are using different terminology, as there would seem to
> be no reason that a target couldn't define that a bool was a 16-bit
> wide datum
I didn't say anything about bools. See? You're making the same wrong
assumptions GCC makes. "bool" should be a well-known name. BImode
shouldn't. My chip has an addressing mode that addresses individual
bits, has nothing to do with the "bool" type.
> (in essence, there needs to be a mechanism by which a target may
> define the it's address resolution, and alignment requirements,
> independently
The chip I'm working on has three addressing modes, with two different
resolutions and alignments. Your assumption - that there is one
address resolution - already breaks my chip.
> >> target_word_mode // presumably the target's largest addressable datum.
> >
> > BLKmode in all cases. Also not useful.
>
> - I hope not, as block mode operands seem to be used for moving data
> with finer granularity than the target's word-width when
> initializing char
You said largest addressable, not largest alignment. More
assumptions. On some chips, for example, "words" may be unaligned,
but "floats" must be aligned. Your "well known name" is already
wrong.
> - no?, I presume that "target_word_mode" would merely describe
> (mentioned above), an aspect of the physical target's natural memory
> access granularity,
You're assuming the target has ONE "natural" access granularity. Just
the dichotomy between scalars and reals breaks that.
My chip has four "natural" accessing granularities. Which would I
choose? (yes, I was stumped for UNITS_PER_WORD because it was used
for many things, and I needed different things it was used for to work
with different sized data).
Heck, the i386 has five natural modes (QI, HI, SI/SF, DI/DF TF). Pick
one.
> - understood, although it would seem much easier if the MI portion simply
> identified the type of pointer it required based upon the context of the
> access which it inherently knows (which the target may map to whatever
"inherently" is misleading. The MI has two feasible options - assume
all pointers are the same, or let the target decide. There is no
usable middle ground.
> mode it desires), rather than the target having to try to figure
> out based upon the more limited tree/rtx context visible to it?)
The tree/decl/rtx is all the MI has too.
> - understood, although hardly believe that it's a problem to require that
> a target define the logical->physical mapping required for for the 20
> or so logically distinct type variations that the MI portion is and
> should be aware of (rather than subject the mapping to any mishandling)
Ok, next time a new language front and is added with new data types,
you get to update all the target backends.
> - I do believe were just using somewhat different terminology, as the MI
> portion of the compiler does and must deal with "well known named" typed
> operations and operands.
Does? Yes. Must? No, outside of the *language* types (not the
*target* types).
> - sorry, I don't see; as the program code, and internal tree representation
> of that code (as you've noted below), identifies all nodes as having one
> of N canonical types (bool, char, short, int, *, [], etc.) not an
> arbitrary type,
*Except* when you consider __attribute__ which can modify *anything*
in gcc. This is how we get vector variables, interrupt functions,
etc.
> - why bother if: TYPE_MODE :: *target_type_mode, i.e:
>
> typedef struct {
> char* name;
> char* mode:
> char size:
> enum attribute {is_signed, is_unsigned, is_floating, is_void};
> } target_type_mode;
No, you're missing a lot of variability here.
> if (TYPE_MODE(...) == char_mode) ...
I'd rather see
if (TYPE_MODE(...) == TYPE_MODE(...))
or
if (BITS_PER_MODE (TYPE_MODE (...)) <= BITS_PER_BYTE)
