Re: Compiling GCC with g++: a report

[Paul Schlie <schlie at comcast dot net>]

> From: 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).

- ?? which was why it seemed to make sense to have the target neutral
  sources refer to "type" modes, i.e. target_int_mode, where then the
  target may declare class machine_mode target_int_mode ("HI", 16),
  to map it in a target specific way to whatever "size" mode it chooses?

  and correspondingly architectural type modes could define more generic
  non-type specific characteristics?

  target_unit_mode // presumably the target's smallest addressable datum.
  target_word_mode // presumably the target's largest addressable datum.

  as there seems no valid reason for the target neutral portion of the
  compiler to ever refer to XXmode under any circumstance?

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

- understood, I think, therefore would expect the target to define
  something like:

  class machine_mode target_code_ptr_mode ("FRED", 24);
  class machine_mode target_rodata_prt_mode ("DINO", 24);
  class machine_mode target_rwdata_ptr_mode ("BARNEY", 16);
  class machine_mode target_stack_ptr_mode ("WILMA", 16);

  where correspondingly the MI portions of GCC utilizes the appropriate
  pointer mode as a function of the type of access being performed,
  where each may mapped as defined by the target to the same or distinct
  modes of it's choosing (where I believe the above four cover the four
  distinct type of semantic accesses GCC seems to need to deal with?)

> 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?"

- or as above, just where target specific machine_mode instance data is
  defined directly for each target data/pointer/architecture "type" mode?

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

- understood, although I honestly don't believe there are that many, and
  it eliminates any possible confusion, and a host of other #defines.

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

- 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"?