Re: What to remove after tree-ssa is merged?

Re: What to remove after tree-ssa is merged?

[Richard Kenner]

    e.g. in previously mentioned examples a COMPONENT_REF where the actual
    offset depends on the size of an array which depends on the value of a
    variable.

No, that's not correct.  It doesn't depend on the value of a
*variable* but on a value within the instance of the type.  There is
nothing to make it explicit *into* since the intent of the node is
that the value is to be obtained individually and at run-time from
each instance of an object of that type.

Re: What to remove after tree-ssa is merged?

[Paul Brook]

On Wednesday 04 February 2004 6:46 pm, Richard Kenner wrote:
>     e.g. in previously mentioned examples a COMPONENT_REF where the actual
>     offset depends on the size of an array which depends on the value of a
>     variable.
>
> No, that's not correct.  It doesn't depend on the value of a
> *variable* but on a value within the instance of the type.  There is
> nothing to make it explicit *into* since the intent of the node is
> that the value is to be obtained individually and at run-time from
> each instance of an object of that type.

I'd include "value within the instance of the type" in the definition of 
"variable".

It _can_ be made explicit. We may not know the actual value, but for a given 
expression we do know which instance we want to extract it from (by walking 
back to a corresponding WITH_RECORD_EXPR). Depending on the method used some 
high level type information may be lost.

In this and previous threads several methods of doing this have been 
suggested. These range from decomposing effected COMPONENT_REFs into pointer 
arithmetic to creating a new subtype for each expression used in a 
WITH_RECORD_EXPR.

I'm not saying lowering in the frontend is the best solution, but it is 
certainly an option. Based on your previous messages I don't believe you know 
enough of the workings of the tree-ssa optimizers to be able to estimate the 
work involved adding WITH_RECORD_EXPR.

I certainly don't claim to be able to make that judgement.

Paul

Re: What to remove after tree-ssa is merged?

[Richard Henderson]

For the record, I believe PLACEHOLDER_EXPR and WITH_RECORD_EXPR should
be nodes in GENERIC, since Ada is not the only language that has variant
records of this sort.  They will *not* be part of GIMPLE -- invisible
references such as this are deadly to optimizers.

So, when the time times, some one will need to implement a gimplifier
for these nodes.  No point in doing it now though, since there's nothing
that could test it.



r~

Re: What to remove after tree-ssa is merged?

[Richard Kenner]

    I fail to see how this is a problem. The frontend passes complete
    functions to the optimizer. I agree that PLACEHOLDER_EXPR is a very
    useful in the frontend when building trees. However I can't see how it
    is of any use once the tree has been built.

    Once the optimizers see a function, haven't we already determined all
    uses of these expressions? Do you have any examples of the when an
    optimier would unexpectedly decide it needs to use one of these
    expressions?

I suspect we're saying the same thing: you won't find PLACEHOLDER_EXPR
in anything that comes from *statements*, but they will remain in the
trees describing *types*.  The optimizer wouldn't see them, but the
Dwarf output routines would, for example.

Re: What to remove after tree-ssa is merged?

[Richard Kenner]

    The information must be there somewhere. Whenever these size or bound 
    expressions are used, it surely must be in the context of a particular 
    object. The RTL expanders manage it quite happily.

When they are *used*, sure.  But the point is that they are also present
in the bounds expressions *to be used* and there is nothing they can be
substituted with in that context.

Re: What to remove after tree-ssa is merged?

[Paul Brook]

On Wednesday 04 February 2004 9:28 pm, Richard Kenner wrote:
>     The information must be there somewhere. Whenever these size or bound
>     expressions are used, it surely must be in the context of a particular
>     object. The RTL expanders manage it quite happily.
>
> When they are *used*, sure.  But the point is that they are also present
> in the bounds expressions *to be used* and there is nothing they can be
> substituted with in that context.

To be used when?

I fail to see how this is a problem. The frontend passes complete functions to 
the optimizer. I agree that PLACEHOLDER_EXPR is a very useful in the frontend 
when building trees. However I can't see how it is of any use once the tree 
has been built.

Once the optimizers see a function, haven't we already determined all uses of 
these expressions? Do you have any examples of the when an optimier would 
unexpectedly decide it needs to use one of these expressions?

Paul

Re: What to remove after tree-ssa is merged?

[Richard Kenner]

    For the record, I believe PLACEHOLDER_EXPR and WITH_RECORD_EXPR should
    be nodes in GENERIC, since Ada is not the only language that has variant
    records of this sort.

I'm not convinced that WITH_RECORD_EXPR needs to be there.  If you're going
to simplify the result by doing the substition, why have the node in the
first place: why not just do the substitution instead of making node?

Re: What to remove after tree-ssa is merged?

[Richard Henderson]

On Wed, Feb 04, 2004 at 04:11:45PM -0500, Richard Kenner wrote:
> I'm not convinced that WITH_RECORD_EXPR needs to be there.

It doesn't *need* to be there, but we have other GENERIC nodes
that we don't *need* either, and which we lower to simpler nodes
during gimplification.


r~

Re: What to remove after tree-ssa is merged?

[Geert Bosch]

On Feb 5, 2004, at 00:32, Richard Henderson wrote:

> On Wed, Feb 04, 2004 at 04:11:45PM -0500, Richard Kenner wrote:
>> I'm not convinced that WITH_RECORD_EXPR needs to be there.
>
> It doesn't *need* to be there, but we have other GENERIC nodes
> that we don't *need* either, and which we lower to simpler nodes
> during gimplification.

Still there is the issue of the P_E, which I think should be resolved
in some way before tree-ssa is integrated. With "resolved' I mean here
the general path that should be followed for replacement. A clear
description or specification in terms of GENERIC or GIMPLE
functionality would suffice here, instead of an actual implementation.

Robert or Richard, could you give a very concise Ada example
that shows why P_E is needed and how it is used? This should be
an example that shows why simple expansion wouldn't be satisfactory.
View this as a challenge to represent in GIMPLE.

If we can agree on this in sufficiently generic terms (no pun
intended) then we can worry later about how to implement this
functionality exactly.

   -Geert

Re: What to remove after tree-ssa is merged?

[Richard Kenner]

    It _can_ be made explicit. We may not know the actual value, but for a
    given expression we do know which instance we want to extract it from
    (by walking back to a corresponding WITH_RECORD_EXPR). 

But there *is* no corresponding WITH_RECORD_EXPR when the expression
is used as a size, offset or bound: that's precisely the point.

Sure, when there is such an expression it can indeed be folded (or not even
generated at all).

Re: What to remove after tree-ssa is merged?

[Paul Brook]

On Wednesday 04 February 2004 8:58 pm, Richard Kenner wrote:
>     It _can_ be made explicit. We may not know the actual value, but for a
>     given expression we do know which instance we want to extract it from
>     (by walking back to a corresponding WITH_RECORD_EXPR).
>
> But there *is* no corresponding WITH_RECORD_EXPR when the expression
> is used as a size, offset or bound: that's precisely the point.

The information must be there somewhere. Whenever these size or bound 
expressions are used, it surely must be in the context of a particular 
object. The RTL expanders manage it quite happily.

Paul

Re: What to remove after tree-ssa is merged?

[Richard Kenner]

    Of course.  But somewhen you _do_ apply it to an object.  Otherwise it
    wouldn't have any observable effect and you couldn't lower it to RTL.  
    And then it can be equally well lowered to trees.

Yes.  As I said, this can be done in trees that are part of *statement*,
but not in trees that are part of *types* and the mechanisms that compute
offsets and sizes (and hence likely fold) will need to know what to do 
about it, albeit transiently.

    Sure, all expressions involving any P_E recursively would have to be
    expanded in the frontend, including such expressions (probably by
    using temporaries in order not to have to lower the whole tree).  If
    that's feasible I don't know.

You won't need temporaries within statements and it can't be done at all
for the expressions within types.

Re: What to remove after tree-ssa is merged?

[Paul Brook]

On Wednesday 04 February 2004 5:57 pm, Richard Kenner wrote:
>     Sure, all expressions involving any P_E recursively would have to be
>     expanded in the frontend, including such expressions (probably by
>     using temporaries in order not to have to lower the whole tree).  If
>     that's feasible I don't know.
>
> You won't need temporaries within statements and it can't be done at all
> for the expressions within types.

It seems to me that the basic problem is thet there are expressions implicit 
in the typing system, and two solutions to this:

(a) Lower these in the frontend/gimplifier and make all the implicit 
expressions explicit. This is what is done for C99 VLAs.

(b) Teach the optimizers about these implicit expressions.

Neither of these seems particularly easy to my unexperienced eye.
On mainline we effectively have a bit of both. ie. constant folding does (b) 
and then it gets expanded to RTL, which does (a).

There doesn't seem to be any consensus on which of these is easiest/best for 
tree-ssa.

Is there any point continuing this thread given we don't have an 
implementation of either, and no frontend(s) to test them with.

Paul

N.B. By "implicit expression" I mean an expression which depends on a variable 
not mentioned directly.
e.g. in previously mentioned examples a COMPONENT_REF where the actual offset 
depends on the size of an array which depends on the value of a variable.

Re: What to remove after tree-ssa is merged?

[Richard Kenner]

    Probably I'm asking the wrong thing because I'm in turn unsure, where 
    exactly P_E is used inside types.

Within the expressions for
	TYPE_MIN_VALUE
	TYPE_MAX_VALUE
	DECL_FIELD_OFFSET
	TYPE_SIZE
	TYPE_SIZE_UNIT

    The example you gave (as I understood it) happens to actually use the
    P_E only in the context of an expression (a COMPONENT_REF in fact),
    also if the P_E expression was only found by looking into the type of
    the bounded array.

Looking into a type, yes, but I'm not sure what you mean by "bounded array".

    So in that example the P_E is used in expressions, so they could be
    lowered to trees not containing P_E (this involves probably making
    some element references more explicit).  

But you don't have the *object* to make it more explicit when it's inside
the type.  That's the whole point: it applies to every *object* of the type.

    To that question you then mentioned P_E inside types, but they should only
    matter for type comparing or in context of expressions AFAICS.  

    the latter can be done with the above frontend specific lowering.

No, because it has to be done by the code that computes sizes and offsets
in the middle end.

Re: What to remove after tree-ssa is merged?

[Michael Matz]

Hi,

On Wed, 4 Feb 2004, Richard Kenner wrote:

> Looking into a type, yes, but I'm not sure what you mean by "bounded array".

Hmm, in your example you used a type representing an array with bounds.

>     So in that example the P_E is used in expressions, so they could be
>     lowered to trees not containing P_E (this involves probably making
>     some element references more explicit).  
> 
> But you don't have the *object* to make it more explicit when it's
> inside the type.  That's the whole point: it applies to every *object*
> of the type.

Of course.  But somewhen you _do_ apply it to an object.  Otherwise it
wouldn't have any observable effect and you couldn't lower it to RTL.  
And then it can be equally well lowered to trees.

>     To that question you then mentioned P_E inside types, but they should only
>     matter for type comparing or in context of expressions AFAICS.  
> 
>     the latter can be done with the above frontend specific lowering.
> 
> No, because it has to be done by the code that computes sizes and offsets
> in the middle end.

Sure, all expressions involving any P_E recursively would have to be 
expanded in the frontend, including such expressions (probably by using 
temporaries in order not to have to lower the whole tree).  If that's 
feasible I don't know.


Ciao,
Michael.

Re: What to remove after tree-ssa is merged?

[Richard Kenner]

    Or are P_E in types also used to actually influence code generation 
    (instead of P_E just in expressions/statements).  And in that case: why is 
    this so, and why are P_E in statements not usable for this?

I'm not sure I understand what you mean.

PLACEHOLDER_EXPR describes a fundamental property of the type from an
implementation standpoint: that in order to compute an offset or size you
need to look inside an object of that type at runtime for a value and use
that value in the computation.

"code generation", of course, is ambiguous here since it's not clear if it
means generation of code trees or RTL.

It's certainly needed for the former and may be needed for the latter.

    FWIW I know that you indeed need this treecode somewhere, it's just
    the question if it needs to be in GIMPLE, and hence has to be handled
    by the middle end, or if it can be isolated to the frontend.

I don't know GIMPLE, so I can't answer that question, but the issue is when
are COMPONENT_REFs lowered?  Because that's when these are used.

A classic case is a record that has two variable-sized arrays, where the
bounds of the arrays are a function of "discriminants", which are other
(earlier) fields in the record.  Consider the second array.  Its
DECL_FIELD_BITPOS will be a function of a PLACEHOLDER_EXPR whose type is the
record in question.

If you have an ARRAY_REF of a COMPONENT_REF pointing into that second array,
the offset needed will depend on a PLACEHOLDER_EXPR.  However, we can
probably get rid of WITH_RECORD_EXPR.  Instead, we can recompute the tree at
that point to do the same substitutions at that point that now happen when
RTL is generated.  The reason this wasn't done before was to avoid the extra
memory since it could easily be done at RTL generation time.  But here, we
don't want to do that.

Re: What to remove after tree-ssa is merged?

[Michael Matz]

Hi,

On Wed, 4 Feb 2004, Richard Kenner wrote:

>     Or are P_E in types also used to actually influence code generation 
>     (instead of P_E just in expressions/statements).  And in that case: why is 
>     this so, and why are P_E in statements not usable for this?
> 
> I'm not sure I understand what you mean.

Probably I'm asking the wrong thing because I'm in turn unsure, where 
exactly P_E is used inside types.  The example you gave (as I understood 
it) happens to actually use the P_E only in the context of an expression 
(a COMPONENT_REF in fact), also if the P_E expression was only found by 
looking into the type of the bounded array.

So in that example the P_E is used in expressions, so they could be 
lowered to trees not containing P_E (this involves probably making some 
element references more explicit).  Basically in the frontend you would 
somehow lower all expressions referencing any P_E to something carrying 
out the necessary calculations explicitely.  I don't yet see, where this 
would not work.

To that question you then mentioned P_E inside types, but they should only
matter for type comparing or in context of expressions AFAICS.  The former
needs language specific type callbacks (or the frontend doesn't leak such
types to the middle end), the latter can be done with the above frontend
specific lowering.


Ciao,
Michael.

Re: What to remove after tree-ssa is merged?

[Robert Dewar]

Note from Richard's explanation of how placeholders work, it would
be really horrible if the front end had to do this, since it would
mean that all references to fields in records had to be handled
with explicit generated offset computations in the front end. This
causes code explosion, obscuring of the intermediate code, and also
debugging difficulties.

It is of course always possible to have the front end do everything,
since of course it could convert the whole program to simple 
combinators, but the fact that this can be done does not necessarily 
make it a good idea.

I think there is real merit in having the type system of gcc be powerful 
enough to reflect the high level types in the various languages for 
which there are front ends.

RE: What to remove after tree-ssa is merged?

[Richard Kenner]

    The reasoning so far has been: If it can be expressed in RTL,
    then there has to be an equivalent representation in trees.
    So basically we hope that PLACEHOLDER_EXPRs can be expanded
    to an equivalent tree without PLACEHOLDER_EXPPs, i.e. making
    this node an Ada language-specific tree node.  

No, I don't think that's the best approach because of its critical
role inside expressions for offsets and sizes.

Re: What to remove after tree-ssa is merged?

[Richard Kenner]

    I've read the docu and think know when you need it (although I'm not sure
    about the specifics of how they are evaluated to RTL), but I don't see a
    reason why this can't be in the front-end, and lowered to trees which do
    not contain PLACEHOLDER_EXPR or WITH_RECORD_EXPR.  After all the functions
    in expr.c even manage to lower such trees to RTL, so there must be some
    way to lower them to GIMPLE which are higher level, isn't there?

There are two separate issues:

(1) The usage of PLACEHOLDER_EXPR in statements.
(2) The usage in types.

For (1), as I said, it is probably possible to fold the PLACEHOLDER_EXPR
into the appropriate object at some point precisely because, as you say,
this can be done when it's lowered to RTL.  So this usage indeed isn't
a problem.

But I don't see how to eliminate the usage in (2).  So the node can't
be eliminated.

Re: What to remove after tree-ssa is merged?

[Michael Matz]

Hi,

On Wed, 4 Feb 2004, Richard Kenner wrote:

> But I don't see how to eliminate the usage in (2).  So the node can't be
> eliminated.

The question (to me) is, what purpose does it have inside types?  Is it
just for describing the type accurately, and ultimately only to decide
sameness of types.  In that case a frontend dependend type_equal_p would
help.

Or are P_E in types also used to actually influence code generation 
(instead of P_E just in expressions/statements).  And in that case: why is 
this so, and why are P_E in statements not usable for this?

FWIW I know that you indeed need this treecode somewhere, it's just the
question if it needs to be in GIMPLE, and hence has to be handled by the
middle end, or if it can be isolated to the frontend.


Ciao,
Michael.

RE: What to remove after tree-ssa is merged?

[S. Bosscher]

The reasoning so far has been: If it can be expressed in RTL,
then there has to be an equivalent representation in trees.
So basically we hope that PLACEHOLDER_EXPRs can be expanded
to an equivalent tree without PLACEHOLDER_EXPPs, i.e. making
this node an Ada language-specific tree node.  If it is
impossble to represent the semantics of a PLACEHOLDER_EXPR
in a lowered tree, then we'll have to revisit this issue.

Gr.
Steven


-----Original Message-----
From: kenner@vlsi1.ultra.nyu.edu
To: pinskia@physics.uc.edu
Cc: gcc@gcc.gnu.org
Sent: 2/4/04 3:39 PM
Subject: Re: What to remove after tree-ssa is merged?

    Should really PLACEHOLDER_EXPR be done in the front-end
    and be expanded to what it really does in gimplify stage
    which every other language needs to do with its language
    specific trees.

Read the documentation and explain what you propose expanding it *to*.
There's no way to express the needed semantics without this or something
very similar.

Re: What to remove after tree-ssa is merged?

[Richard Kenner]

    If you are playing this trick where is this documentation, 

Where it belongs: there is a very large description in front of
the PLACEHOLDER_EXPR line in tree.def.

Re: What to remove after tree-ssa is merged?

[Richard Kenner]

    Should really PLACEHOLDER_EXPR be done in the front-end
    and be expanded to what it really does in gimplify stage
    which every other language needs to do with its language
    specific trees.

Read the documentation and explain what you propose expanding it *to*.
There's no way to express the needed semantics without this or something
very similar.

Re: What to remove after tree-ssa is merged?

[Andrew Pinski]

On Feb 4, 2004, at 06:39, Richard Kenner wrote:

>     Should really PLACEHOLDER_EXPR be done in the front-end
>     and be expanded to what it really does in gimplify stage
>     which every other language needs to do with its language
>     specific trees.
>
> Read the documentation and explain what you propose expanding it *to*.
> There's no way to express the needed semantics without this or 
> something
> very similar.

If you are playing this trick where is this documentation, I do not see 
it in doc/*.texi at
all.  There is only one reference to it in doc and that is the 
documentation for c-trees
(which is a little lacking by the way but it was added the fact) and it 
just says:

Normally these expressions will reference a field in the
outer object using a @code{PLACEHOLDER_EXPR}.
.


Thanks,
Andrew Pinski

Re: What to remove after tree-ssa is merged?

[Michael Matz]

Hi,

On Wed, 4 Feb 2004, Richard Kenner wrote:

> Read the documentation and explain what you propose expanding it *to*.
> There's no way to express the needed semantics without this or something
> very similar.

I've read the docu and think know when you need it (although I'm not sure
about the specifics of how they are evaluated to RTL), but I don't see a
reason why this can't be in the front-end, and lowered to trees which do
not contain PLACEHOLDER_EXPR or WITH_RECORD_EXPR.  After all the functions
in expr.c even manage to lower such trees to RTL, so there must be some
way to lower them to GIMPLE which are higher level, isn't there?


Ciao,
Michael.

RE: What to remove after tree-ssa is merged?

[Richard Kenner]

    It is not required for Ada right now because Ada doesn't work
    with tree-ssa anyway.

Sure, but there's no point in taking something out that we know will have
to be put back!

    And if it will, then we'll have to see how to fit in the thing that
    PLACEHOLDER_EXPR is for now.  I don't know what it is used for at
    present, but there has to be a way (or there will have to be) to
    express the same thing in GIMPLE.

Did you read the documentation on it in tree.def?  Whats's unclear about it?
Here it is for reference:

/* The following two codes are used in languages that have types where
   some field in an object of the type contains a value that is used in
   the computation of another field's offset or size and/or the size of
   the type.  The positions and/or sizes of fields can vary from object
   to object of the same type or even for one and the same object within
   its scope.

   Record types with discriminants in Ada or schema types in Pascal are
   examples of such types.  This mechanism is also used to create "fat
   pointers" for unconstrained array types in Ada; the fat pointer is a
   structure one of whose fields is a pointer to the actual array type
   and the other field is a pointer to a template, which is a structure
   containing the bounds of the array.  The bounds in the type pointed
   to by the first field in the fat pointer refer to the values in the
   template.

   When you wish to construct such a type you need "self-references"
   that allow you to reference the object having this type from the
   TYPE node, i.e. without having a variable instantiating this type.

   Such a "self-references" is done using a PLACEHOLDER_EXPR.  This is
   a node that will later be replaced with the object being referenced.
   Its type is that of the object and selects which object to use from
   a chain of references (see below).  No other slots are used in the
   PLACEHOLDER_EXPR.

   For example, if your type FOO is a RECORD_TYPE with a field BAR,
   and you need the value of <variable>.BAR to calculate TYPE_SIZE
   (FOO), just substitute <variable> above with a PLACEHOLDER_EXPR
   whose TREE_TYPE is FOO.  Then construct your COMPONENT_REF with
   the PLACEHOLDER_EXPR as the first operand (which has the correct
   type).  Later, when the size is needed in the program, the back-end
   will find this PLACEHOLDER_EXPR and generate code to calculate the
   actual size at run-time.  In the following, we describe how this
   calculation is done.

   When we wish to evaluate a size or offset, we check whether it
   contains a PLACEHOLDER_EXPR.  If it does, we construct a
   WITH_RECORD_EXPR that contains both the expression we wish to
   evaluate and an expression within which the object may be found.
   The latter expression is the object itself in the simple case of an
   Ada record with discriminant, but it can be the array in the case of
   an unconstrained array.

   In the latter case, we need the fat pointer, because the bounds of
   the array can only be accessed from it.  However, we rely here on the
   fact that the expression for the array contains the dereference of
   the fat pointer that obtained the array pointer.

   Accordingly, when looking for the object to substitute in place of
   a PLACEHOLDER_EXPR, we look down the first operand of the expression
   passed as the second operand to WITH_RECORD_EXPR until we find
   something of the desired type or reach a constant.  */

/* Denotes a record to later be supplied with a WITH_RECORD_EXPR when
   evaluating this expression.  The type of this expression is used to
   find the record to replace it.  */
DEFTREECODE (PLACEHOLDER_EXPR, "placeholder_expr", 'x', 0)

/* Provide an expression that references a record to be used in place
   of a PLACEHOLDER_EXPR.  The record to be used is the record within
   operand 1 that has the same type as the PLACEHOLDER_EXPR in
   operand 0.  */
DEFTREECODE (WITH_RECORD_EXPR, "with_record_expr", 'e', 2)

RE: What to remove after tree-ssa is merged?

[S. Bosscher]

It is not required for Ada right now because Ada doesn't work
with tree-ssa anyway.  And if it will, then we'll have to see
how to fit in the thing that PLACEHOLDER_EXPR is for now.  I
don't know what it is used for at present, but there has to be
a way (or there will have to be) to express the same thing in
GIMPLE.

But since Ada is lagging, like, three years on the rest of GCC,
and nobody so far has explained what PLACEHOLDER_EXPR is for
and if/how it has a GIMPLE equivalent...

Gr.
Steven

 
-----Original Message-----
From: kenner@vlsi1.ultra.nyu.edu
To: paolo.bonzini@polimi.it
Cc: gcc@gcc.gnu.org
Sent: 2/4/04 1:32 PM
Subject: Re:  What to remove after tree-ssa is merged?

    I remember you also removed PLACEHOLDER_EXPR.

That's required for Ada, so can't be removed.

Re: What to remove after tree-ssa is merged?

[Paul Brook]

On Wednesday 04 February 2004 1:26 pm, S. Bosscher wrote:
> It is not required for Ada right now because Ada doesn't work
> with tree-ssa anyway.  And if it will, then we'll have to see
> how to fit in the thing that PLACEHOLDER_EXPR is for now.  I
> don't know what it is used for at present, but there has to be
> a way (or there will have to be) to express the same thing in
> GIMPLE.

I think it's worth explicity pointing out that PLACEHOLDER_EXPR doesn't work 
on tree-ssa anyway. I don't see how removing it effects ada as it would need 
to be reimplemented anyway when ada moves to tree-ssa.

To put it annother way: there's no way to tell if we break it, so it's not 
going to get fixed. Hence we may as well remove it.

If you really think the existing remnants are important then that's what we 
have CVS history for.

Paul

RE: What to remove after tree-ssa is merged?

[Michael Matz]

Hi,

On Wed, 4 Feb 2004, S. Bosscher wrote:

> But since Ada is lagging, like, three years on the rest of GCC,
> and nobody so far has explained what PLACEHOLDER_EXPR is for

It's not that Kenner is totally wrong with documentation ;-)
PLACEHOLDER_EXPR is described in tree.def and is used for types whose 
layout/content changes with values of members in such type.  Like 
pseudo-type:

  type T {
    switch enum BLA discriminator {
      VARIANT_1 : int i; char c;
      VARIANT_2 : char d; long l;
    }
  }

Here the offset of T.c (or even it's existance) depends on the value of 
T.discriminator.


Ciao,
Michael.

Re: What to remove after tree-ssa is merged?

[Robert Dewar]

It certainly seems unfortunate that tree-ssa removes a
critical (well documented :-) part of gcc functionality,
and this omission may well cause significant delays
in bringing Ada up to tree-ssa level. Are there any
other features that are being removed like this?

Re: What to remove after tree-ssa is merged?

[Andrew Pinski]

On Feb 4, 2004, at 06:18, Robert Dewar wrote:

> It certainly seems unfortunate that tree-ssa removes a
> critical (well documented :-) part of gcc functionality,
> and this omission may well cause significant delays
> in bringing Ada up to tree-ssa level. Are there any
> other features that are being removed like this?


Should really PLACEHOLDER_EXPR be done in the front-end
and be expanded to what it really does in gimplify stage
which every other language needs to do with its language
specific trees.


Thanks,
Andrew Pinski

Re: What to remove after tree-ssa is merged?

[Robert Dewar]

Andrew Pinski wrote:

> Should really PLACEHOLDER_EXPR be done in the front-end
> and be expanded to what it really does in gimplify stage
> which every other language needs to do with its language
> specific trees.

I don't think there is any clean translation here. Remember
that we tried this route energetically early on in Ada days
and failed, that is why PLACEHOLDER_EXPR was created to do
this task.

We really don't want that severe a mismatch between the
front end types and the back end types, a mismatch of that
level causes a lot of grief.

I am sure Richard can add more useful details here.

Re: What to remove after tree-ssa is merged?

[Richard Kenner]

    I remember you also removed PLACEHOLDER_EXPR.

That's required for Ada, so can't be removed.

Re: "Documentation by paper"

[Richard Kenner]

    Everybody with less than guru knowledge of gcc asks, why.  And why CSE
    propagates addressof into memories.  And who takes care of it for
    nonoptimizing compilation.  And whether it is even needed for
    nonoptimizing compilation.  And the flow of thought goes on.

Indeed.  The ADDRESSOF addition was one that gave GCC a lot of
trouble, precisely because of the issues you raise, that its semantics
were very poorly defined.

I see that as cautionary that we need to do better in the future, not
as something to emulate into the future!

    Passes that are developed right now, especially as part of the
    tree-ssa work (but also Jan and Zdenek's rtlopt work), work at a
    different, more generic level, and require a different kind of culture
    on the reader.

Perhaps, but we have to be very careful of setting too high a level of
knowlege to know to be able to work on GCC.  Sure, if you're working on
subtle parts of these algorithms, you need to understand them "cold", but
an overview description is essential for those doing minor work in these
files.

As I said, the Bison manual even defines the term "symbol".  That sort of
approach seems the appropriate one to me.

Re: "Documentation by paper"

[Jan Hubicka]

>     Everybody with less than guru knowledge of gcc asks, why.  And why CSE
>     propagates addressof into memories.  And who takes care of it for
>     nonoptimizing compilation.  And whether it is even needed for
>     nonoptimizing compilation.  And the flow of thought goes on.
> 
> Indeed.  The ADDRESSOF addition was one that gave GCC a lot of
> trouble, precisely because of the issues you raise, that its semantics
> were very poorly defined.
> 
> I see that as cautionary that we need to do better in the future, not
> as something to emulate into the future!

I hope that addressof will be elliminated soon.  In fact I do have patch
for this for tree-SSA, but still we need to resolve on how to optimize
out the casts of stype *(const char *)&char_variable that occurs
commonly in gimplified C++ code (Richard Henderson has plans on fixing
C++ FE to avoid producing this, so hope this will be sorted out soon)
> 
>     Passes that are developed right now, especially as part of the
>     tree-ssa work (but also Jan and Zdenek's rtlopt work), work at a
>     different, more generic level, and require a different kind of culture
>     on the reader.
> 
> Perhaps, but we have to be very careful of setting too high a level of
> knowlege to know to be able to work on GCC.  Sure, if you're working on
> subtle parts of these algorithms, you need to understand them "cold", but
> an overview description is essential for those doing minor work in these
> files.

I would agree here that the notion of counts/frequencies/probabilites,
hottness/coldness of basic block and various types of edges is midly
confusing (the last one even to someone who knows what CFG/profile is).

I tried to use quite precise names that results in longer identifiers
(like maybe_hot_bb_p/probably_cold_bb_p) that indicate what kind of
approximation it is, but it is still not very obvous.

I wrote chaper to gccint.texi devoted to the CFG and profile and I think
it is quite shame that it never has been accepted.  Steven has updated
version.  This only show that it is quite dificult to judge where the
documentation shall go in the current scheme.

Honza
> 
> As I said, the Bison manual even defines the term "symbol".  That sort of
> approach seems the appropriate one to me.

What to remove after tree-ssa is merged?

[Paolo Bonzini]

> I hope that addressof will be elliminated soon.  In fact I do have patch
> for this for tree-SSA

I remember you also removed PLACEHOLDER_EXPR.

I vote for CONSTANT_P_RTX (I also have a patch for it).

Paolo