Re: General question about types of tree expressions

[Paul Schlie <schlie at comcast dot net>]

> From: Daniel Berlin <dberlin@dberlin.org>
> On Wed, 2005-02-09 at 12:43 -0500, Paul Schlie wrote:
>>> Daniel Berlin writes:
>>> The document i've been working on defining the semantics of gimple
>>> operations specifically states that all binary and unary operators
>>> must have operands of the same type.
>> 
>> Out of curiosity, wouldn't it be both simpler and more efficient to
>> define the semantics such that operands are "implied" to have the same
>> type as the node itself, thereby eliminate the otherwise necessity to
>> literally insert cast operators into the tree, which are already implied
>> by the semantics of the operation itself (except as may otherwise be
>> required to denote that sign extension for promoted signed integers, but
>> not otherwise required for unsigned, down-cast, or other type conversions)?
> 
> You don't insert cast operators into the operator tree, you insert them
> in the statements before the operation.
> If we need casts to make the operands the same, they should be there
> anyway (they are implicitly when they are expanded).

Then I guess confused by your earlier message:

> From: Daniel Berlin:
> The document i've been working on defining the semantics of gimple
> operations specifically states that all binary and unary operators must
> have operands of the same type.
>
> I've got a verifier that verifies this, and as one would expect, it
> catches quite a few "issues" right now.

As then how could there be "issues" if all operands are implied as being
cast to their respective required types (without needing to be explicit)?

So for the sake argument (trying to explain my confusion), given a program
fragment:

  unsigned short us = something;
  signed int si = something_else;

  (char *)(&us) = (si >> us);

Would think the simplest representation to be something like:

 (SET:char (VAR:u-short us) (RSHIFT:int (VAR:s-int si) (VAR:u-short us)))

As if the semantics of operators were defined to always have their operands
presumed to be of the same type of the operation, it's operands need not be
explicitly cast within it's representation, as they'd be implied to be so,
therefore always correct by construction; as I thought I understood from
your above comment?