Re: Patch: stab info for const fields

Re: Patch: stab info for const fields

[Richard Kenner]

     - In the language-independent tree representation, whenever a tree
       with type A has an operand with type B, A not identical to B, the
       operand is implicitly converted to type A before the operation
       occurs.

But what does that mean?  That's the essence of the problem.

Please go back to the originally-stated question: if a see a PLUS_EXPR and
look at its type and the types of its operands, how do I know if that's
a valid tree node in our IL?  If the answer is "you look at the definition
of the language it's written in", that's a serious problem in my view.

Re: Patch: stab info for const fields

[Andrew Haley]

Richard Kenner writes:
 >      - In the language-independent tree representation, whenever a tree
 >        with type A has an operand with type B, A not identical to B, the
 >        operand is implicitly converted to type A before the operation
 >        occurs.
 > 
 > But what does that mean?  That's the essence of the problem.
 > 
 > Please go back to the originally-stated question: if a see a PLUS_EXPR and
 > look at its type and the types of its operands, how do I know if that's
 > a valid tree node in our IL?  If the answer is "you look at the definition
 > of the language it's written in", that's a serious problem in my view.

You seem to have smipped

   Most of the time there is just one, well-defined, conversion
   operation that makes sense in any such context.  If there is none,
   or if there could be multiple intended semantics, the tree is
   ill-formed; the middle-end will abort if handed such a tree.

So the question becomes: "in what circumstances is there just one,
well-defined, conversion that makes sense?"  If we properly define
those circumstances the problem is solved.

Andrew.

Re: Patch: stab info for const fields

[Richard Kenner]

    So the question becomes: "in what circumstances is there just one,
    well-defined, conversion that makes sense?"  If we properly define
    those circumstances the problem is solved.

Sure, but, as I said, that's precisely equivalent to the original question.

Re: Patch: stab info for const fields

[Richard Kenner]

    I believe that Zack implicitly meant (3), using a superset of (2).

OK, what *is* that superset?  How is it defined precisely? 

Re: Patch: stab info for const fields

[Andrew Haley]

Richard Kenner writes:
 >     You seem to have smipped
 > 
 >        Most of the time there is just one, well-defined, conversion
 >        operation that makes sense in any such context.  If there is none,
 >        or if there could be multiple intended semantics, the tree is
 >        ill-formed; the middle-end will abort if handed such a tree.
 > 
 >     So the question becomes: "in what circumstances is there just one,
 >     well-defined, conversion that makes sense?"  If we properly define
 >     those circumstances the problem is solved.
 > 
 > Well, that's exactly what we're trying to do: to "properly define" what
 > "implicit conversions" are valid.  What is your proposal?
 > 
 > To restate the four that we've talked about into that terminology, they are:
 > 
 > (1) None.
 > (2) Only between types whose TYPE_MAIN_VARIANT are the same.
 > (3) Some other, language-independent formulation.
 > (3a) A language-dependent formulation.
 > 
 > So we're back to the original question.

I believe that Zack implicitly meant (3), using a superset of (2).
This has the advantage of economy because we won't be generating tree
nodes for many implicit conversions.

For example, we might decide that widening signed and unsigned
integers is well-defined, whereas narrowing is not.

Andrew.

Re: Patch: stab info for const fields

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| On Fri, Nov 01, 2002 at 01:21:17AM +0100, Gabriel Dos Reis wrote:
| > kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
| > 
| > |     If you look again at the bit you snipped, the implementation I
| > |     suggested should be totally language-independent (in the
| > |     language-independent parts of the compiler).
| > | 
| > | Yes, the *implementation* is, but the *definition* is not, so that when
| > | people are looking at a tree, they can't know whether it's valid or not
| > | without knowlege of the language in question and I think that's a bad idea.
| > 
| > I strongly agree with Kenner on this point.  There ought to be a
| > precise definition.  I support option (1) and won't oppose to (2).
| > But (3) or (3a) aren't workable, IMO.
| 
| I really don't understand the objections here.  The definition I had
| in mind had no language dependencies either in the definition or the
| implementation.

Maybe what you had in mind has no language dependency, but that is not
transparent from the description you gave and at two persons don't see
the non-dependency.  If your definition is language independent and
precise then there ought to be possible to express it so that we can
check that the implementation matches what you intended and also our
understanding. 

|  Let me go over it again hopefully described better:
| 
|  - We get rid of the ambiguously defined NOP_EXPR and CONVERT_EXPR.

This part I do understand.

|  - In the language-independent tree representation, whenever a tree
|    with type A has an operand with type B, A not identical to B, the
|    operand is implicitly converted to type A before the operation
|    occurs.  Most of the time there is just one, well-defined,
|    conversion operation that makes sense in any such context.  If
|    there is none, or if there could be multiple intended semantics,
|    the tree is ill-formed; the middle-end will abort if handed such a
|    tree.  (Examples: coercion between float and integer has several
|    possible semantics, and it's ambiguous which one is meant; coercion
|    between aggregate types is ill-defined.)

I see that your examples try to make more precise the preceeding
assertion. IMO, we ought to define precisely the exceptional cases so
that every can check that the description is really language
indepeendent.

[...]

| Does it make more sense now? 

For me, that sheds more light on what you said earlier.  Still, I'm
uncomfortable with the non-exceptional cases not being precisely
defined.  If that part is resolved, I would see no reason not to go
with what you're proposing.

-- Gaby

Re: Patch: stab info for const fields

[Richard Kenner]

    You seem to have smipped

       Most of the time there is just one, well-defined, conversion
       operation that makes sense in any such context.  If there is none,
       or if there could be multiple intended semantics, the tree is
       ill-formed; the middle-end will abort if handed such a tree.

    So the question becomes: "in what circumstances is there just one,
    well-defined, conversion that makes sense?"  If we properly define
    those circumstances the problem is solved.

Well, that's exactly what we're trying to do: to "properly define" what
"implicit conversions" are valid.  What is your proposal?

To restate the four that we've talked about into that terminology, they are:

(1) None.
(2) Only between types whose TYPE_MAIN_VARIANT are the same.
(3) Some other, language-independent formulation.
(3a) A language-dependent formulation.

So we're back to the original question.

Re: Patch: stab info for const fields

[Richard Kenner]

    Again, this goes to Zack's point; we can allow two types to be compatible,
    even if they are not the same.  (That idea already exists in C/C++)

So the idea is that we allow "compatible" types on the two operands and
the result of a PLUS_EXPR, but they are not required to all be the same?
We've never really been clear on that and there are three possibilities:

(1) The types are exactly the same.
(2) TYPE_MAIN_VARIANT of the types are the same.
(3) The types are "compatible" (to be defined later).

I've argued for (1) in the past and continue to do so.  Is the above
arguing for (2) or (3)?

Re: Patch: stab info for const fields

[Mark Mitchell]

--On Thursday, October 31, 2002 05:06:41 PM +0000 Richard Kenner 
<kenner@vlsi1.ultra.nyu.edu> wrote:

>     GCC is pretty clear on the idea that the type system is, roughly
>     speaking, the C type system.  The front end's job is to translate its
>     own type system into that type system.
>
> Right, but we haven't been as clear as we should be on what "the C type
> system" is.  That's basically what started this: what about readonly?
> Consider (going back to C):
>
> 	int a;
> 	const int b;
>
> 	... a + b ...
>
> What does that PLUS_EXPR look like?

The C standard indicates that qualifiers do not matter in rvalue
contexts.

>     If you have declarations whose size is not that of their type, you
>     have to say more about what tree operations are legal in the middle
>     end.  Can you use a MODIFY_EXPR to assign these out-sized objects to
>     ordinary-sized objects?  Normally, the constraint on a MODIFY_EXPR is
>     that the two operands have the same type.  This is but the tip of the
>     iceberg.
>
> Yes, but I think they can all be solved the way the PLUS_EXPR above is:
> the *operation* is, semantically, that of its type.  However, the
> optimizers are allowed to use the fact that B is constant.

Sure -- and they can use that fact even if B is not of type "const int".

If I write:

  int b = 3;

and never modify or take the address of "b", the front end can set
TREE_READONLY on b.

> Similarly
> with a MODIFY_EXPR in the aggregate case: only the size corresponding to
> the type is modified, but if one operand is actually more aligned that
> the type, the optimizer and code generator is allowed to take advantage
> of that.

Again, this goes to Zack's point; we can allow two types to be compatible,
even if they are not the same.  (That idea already exists in C/C++)

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: Patch: stab info for const fields

[Richard Kenner]

    GCC is pretty clear on the idea that the type system is, roughly
    speaking, the C type system.  The front end's job is to translate its
    own type system into that type system.

Right, but we haven't been as clear as we should be on what "the C type
system" is.  That's basically what started this: what about readonly?
Consider (going back to C):

	int a;
	const int b;

	... a + b ...

What does that PLUS_EXPR look like?  If A and B are different types (with
a different TREE_READONLY), then we have to have a conversion in that
PLUS_EXPR.  Sure the optimizer can "do the right thing" and ignore it,
but those conversions aren't making things any easier.

    If you have declarations whose size is not that of their type, you
    have to say more about what tree operations are legal in the middle
    end.  Can you use a MODIFY_EXPR to assign these out-sized objects to
    ordinary-sized objects?  Normally, the constraint on a MODIFY_EXPR is
    that the two operands have the same type.  This is but the tip of the
    iceberg.

Yes, but I think they can all be solved the way the PLUS_EXPR above is:
the *operation* is, semantically, that of its type.  However, the optimizers
are allowed to use the fact that B is constant.  Similarly with a MODIFY_EXPR
in the aggregate case: only the size corresponding to the type is modified,
but if one operand is actually more aligned that the type, the optimizer and
code generator is allowed to take advantage of that.

Re: Patch: stab info for const fields

[Mark Mitchell]

--On Thursday, October 31, 2002 04:38:15 PM +0000 Richard Kenner 
<kenner@vlsi1.ultra.nyu.edu> wrote:

>     It would be great to get all this junk out of DECLs, but it will
>     take some doing...
>
> I'm still not sure it's moving in the right direction.  Consider the
> following in Ada:
>
> 	type Myint is range 0..1000;
> 	for Myint'size use 32;
> 	type T is record f1, f2: Myint; end record;
> 	X: T;
> 	for X'size use 128;
>
> This has X of type T, which is 64 bits, but X is 128 bits.
>
> Currently, GNAT makes a special type for X which is a record of one
> field.  That field is of type T and the type for X has a size of 128 bits.
> Then X is of that type.
>
> But doing this means that all references to X need an implicit
> COMPONENT_REF to extract the actual data.  This is a mess.

Yes, but it's Ada's mess. :-)

GCC is pretty clear on the idea that the type system is, roughly
speaking, the C type system.  The front end's job is to translate
its own type system into that type system.

The current Ada approach is exactly the right one, in that respect.

There's no inherent reason that it should cause any problems; our
optimizers should be able to figure out what's going on.  If they
can't, they will be improved.

If you have declarations whose size is not that of their type, you
have to say more about what tree operations are legal in the middle
end.  Can you use a MODIFY_EXPR to assign these out-sized objects to
ordinary-sized objects?  Normally, the constraint on a MODIFY_EXPR
is that the two operands have the same type.  This is but the tip of
the iceberg.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: Patch: stab info for const fields

[Richard Kenner]

    It would be great to get all this junk out of DECLs, but it will
    take some doing...

I'm still not sure it's moving in the right direction.  Consider the
following in Ada:

	type Myint is range 0..1000;
	for Myint'size use 32;
	type T is record f1, f2: Myint; end record;
	X: T;
	for X'size use 128;

This has X of type T, which is 64 bits, but X is 128 bits.

Currently, GNAT makes a special type for X which is a record of one
field.  That field is of type T and the type for X has a size of 128 bits.
Then X is of that type.

But doing this means that all references to X need an implicit
COMPONENT_REF to extract the actual data.  This is a mess.

If we allow the size of a decl to be larger than that of its type, we
can avoid this mess.