* RE: What to remove after tree-ssa is merged?
@ 2004-02-04 15:16 S. Bosscher
0 siblings, 0 replies; 35+ messages in thread
From: S. Bosscher @ 2004-02-04 15:16 UTC (permalink / raw)
To: 'kenner@vlsi1.ultra.nyu.edu ', 'pinskia@physics.uc.edu '
Cc: 'gcc@gcc.gnu.org '
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
2004-02-05 5:32 ` Richard Henderson
@ 2004-02-05 5:50 ` Geert Bosch
0 siblings, 0 replies; 35+ messages in thread
From: Geert Bosch @ 2004-02-05 5:50 UTC (permalink / raw)
To: Richard Henderson; +Cc: gcc, Richard Kenner
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
2004-02-04 21:09 Richard Kenner
@ 2004-02-05 5:32 ` Richard Henderson
2004-02-05 5:50 ` Geert Bosch
0 siblings, 1 reply; 35+ messages in thread
From: Richard Henderson @ 2004-02-05 5:32 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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~
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
@ 2004-02-04 21:55 Richard Kenner
0 siblings, 0 replies; 35+ messages in thread
From: Richard Kenner @ 2004-02-04 21:55 UTC (permalink / raw)
To: paul; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
2004-02-04 21:25 Richard Kenner
@ 2004-02-04 21:51 ` Paul Brook
0 siblings, 0 replies; 35+ messages in thread
From: Paul Brook @ 2004-02-04 21:51 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
@ 2004-02-04 21:25 Richard Kenner
2004-02-04 21:51 ` Paul Brook
0 siblings, 1 reply; 35+ messages in thread
From: Richard Kenner @ 2004-02-04 21:25 UTC (permalink / raw)
To: paul; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
2004-02-04 20:55 Richard Kenner
@ 2004-02-04 21:21 ` Paul Brook
0 siblings, 0 replies; 35+ messages in thread
From: Paul Brook @ 2004-02-04 21:21 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
@ 2004-02-04 21:09 Richard Kenner
2004-02-05 5:32 ` Richard Henderson
0 siblings, 1 reply; 35+ messages in thread
From: Richard Kenner @ 2004-02-04 21:09 UTC (permalink / raw)
To: rth; +Cc: gcc
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?
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
@ 2004-02-04 20:55 Richard Kenner
2004-02-04 21:21 ` Paul Brook
0 siblings, 1 reply; 35+ messages in thread
From: Richard Kenner @ 2004-02-04 20:55 UTC (permalink / raw)
To: paul; +Cc: gcc
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).
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
2004-02-04 19:49 ` Paul Brook
@ 2004-02-04 20:15 ` Richard Henderson
0 siblings, 0 replies; 35+ messages in thread
From: Richard Henderson @ 2004-02-04 20:15 UTC (permalink / raw)
To: Paul Brook; +Cc: Richard Kenner, gcc
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~
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
2004-02-04 18:43 Richard Kenner
@ 2004-02-04 19:49 ` Paul Brook
2004-02-04 20:15 ` Richard Henderson
0 siblings, 1 reply; 35+ messages in thread
From: Paul Brook @ 2004-02-04 19:49 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
@ 2004-02-04 18:43 Richard Kenner
2004-02-04 19:49 ` Paul Brook
0 siblings, 1 reply; 35+ messages in thread
From: Richard Kenner @ 2004-02-04 18:43 UTC (permalink / raw)
To: paul; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
2004-02-04 17:54 Richard Kenner
@ 2004-02-04 18:39 ` Paul Brook
0 siblings, 0 replies; 35+ messages in thread
From: Paul Brook @ 2004-02-04 18:39 UTC (permalink / raw)
To: Richard Kenner, matz; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
@ 2004-02-04 17:54 Richard Kenner
2004-02-04 18:39 ` Paul Brook
0 siblings, 1 reply; 35+ messages in thread
From: Richard Kenner @ 2004-02-04 17:54 UTC (permalink / raw)
To: matz; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
2004-02-04 15:49 Richard Kenner
2004-02-04 16:10 ` Michael Matz
@ 2004-02-04 17:25 ` Robert Dewar
1 sibling, 0 replies; 35+ messages in thread
From: Robert Dewar @ 2004-02-04 17:25 UTC (permalink / raw)
To: Richard Kenner; +Cc: matz, gcc
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
2004-02-04 16:14 Richard Kenner
@ 2004-02-04 16:39 ` Michael Matz
0 siblings, 0 replies; 35+ messages in thread
From: Michael Matz @ 2004-02-04 16:39 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
@ 2004-02-04 16:14 Richard Kenner
2004-02-04 16:39 ` Michael Matz
0 siblings, 1 reply; 35+ messages in thread
From: Richard Kenner @ 2004-02-04 16:14 UTC (permalink / raw)
To: matz; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
2004-02-04 15:49 Richard Kenner
@ 2004-02-04 16:10 ` Michael Matz
2004-02-04 17:25 ` Robert Dewar
1 sibling, 0 replies; 35+ messages in thread
From: Michael Matz @ 2004-02-04 16:10 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
@ 2004-02-04 15:49 Richard Kenner
2004-02-04 16:10 ` Michael Matz
2004-02-04 17:25 ` Robert Dewar
0 siblings, 2 replies; 35+ messages in thread
From: Richard Kenner @ 2004-02-04 15:49 UTC (permalink / raw)
To: matz; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
2004-02-04 15:19 Richard Kenner
@ 2004-02-04 15:31 ` Michael Matz
0 siblings, 0 replies; 35+ messages in thread
From: Michael Matz @ 2004-02-04 15:31 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* RE: What to remove after tree-ssa is merged?
@ 2004-02-04 15:21 Richard Kenner
0 siblings, 0 replies; 35+ messages in thread
From: Richard Kenner @ 2004-02-04 15:21 UTC (permalink / raw)
To: S.Bosscher; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
@ 2004-02-04 15:19 Richard Kenner
2004-02-04 15:31 ` Michael Matz
0 siblings, 1 reply; 35+ messages in thread
From: Richard Kenner @ 2004-02-04 15:19 UTC (permalink / raw)
To: matz; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
2004-02-04 14:36 Richard Kenner
2004-02-04 14:44 ` Andrew Pinski
@ 2004-02-04 15:15 ` Michael Matz
1 sibling, 0 replies; 35+ messages in thread
From: Michael Matz @ 2004-02-04 15:15 UTC (permalink / raw)
To: Richard Kenner; +Cc: pinskia, gcc
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
2004-02-04 14:31 ` Andrew Pinski
@ 2004-02-04 14:53 ` Robert Dewar
0 siblings, 0 replies; 35+ messages in thread
From: Robert Dewar @ 2004-02-04 14:53 UTC (permalink / raw)
To: Andrew Pinski
Cc: S. Bosscher, 'paolo.bonzini@polimi.it ',
'gcc@gcc.gnu.org ', 'kenner@vlsi1.ultra.nyu.edu ',
Michael Matz
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
@ 2004-02-04 14:48 Richard Kenner
0 siblings, 0 replies; 35+ messages in thread
From: Richard Kenner @ 2004-02-04 14:48 UTC (permalink / raw)
To: pinskia; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
2004-02-04 14:36 Richard Kenner
@ 2004-02-04 14:44 ` Andrew Pinski
2004-02-04 15:15 ` Michael Matz
1 sibling, 0 replies; 35+ messages in thread
From: Andrew Pinski @ 2004-02-04 14:44 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc, 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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
@ 2004-02-04 14:36 Richard Kenner
2004-02-04 14:44 ` Andrew Pinski
2004-02-04 15:15 ` Michael Matz
0 siblings, 2 replies; 35+ messages in thread
From: Richard Kenner @ 2004-02-04 14:36 UTC (permalink / raw)
To: pinskia; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
2004-02-04 14:19 ` Robert Dewar
@ 2004-02-04 14:31 ` Andrew Pinski
2004-02-04 14:53 ` Robert Dewar
0 siblings, 1 reply; 35+ messages in thread
From: Andrew Pinski @ 2004-02-04 14:31 UTC (permalink / raw)
To: Robert Dewar
Cc: S. Bosscher, 'paolo.bonzini@polimi.it ',
'gcc@gcc.gnu.org ', 'kenner@vlsi1.ultra.nyu.edu ',
Andrew Pinski, Michael Matz
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
2004-02-04 14:04 ` Michael Matz
@ 2004-02-04 14:19 ` Robert Dewar
2004-02-04 14:31 ` Andrew Pinski
0 siblings, 1 reply; 35+ messages in thread
From: Robert Dewar @ 2004-02-04 14:19 UTC (permalink / raw)
To: Michael Matz
Cc: S. Bosscher, 'kenner@vlsi1.ultra.nyu.edu ',
'paolo.bonzini@polimi.it ', 'gcc@gcc.gnu.org '
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?
^ permalink raw reply [flat|nested] 35+ messages in thread
* RE: What to remove after tree-ssa is merged?
2004-02-04 13:29 S. Bosscher
2004-02-04 13:49 ` Paul Brook
@ 2004-02-04 14:04 ` Michael Matz
2004-02-04 14:19 ` Robert Dewar
1 sibling, 1 reply; 35+ messages in thread
From: Michael Matz @ 2004-02-04 14:04 UTC (permalink / raw)
To: S. Bosscher
Cc: 'kenner@vlsi1.ultra.nyu.edu ',
'paolo.bonzini@polimi.it ', 'gcc@gcc.gnu.org '
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* RE: What to remove after tree-ssa is merged?
@ 2004-02-04 13:52 Richard Kenner
0 siblings, 0 replies; 35+ messages in thread
From: Richard Kenner @ 2004-02-04 13:52 UTC (permalink / raw)
To: S.Bosscher; +Cc: gcc
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)
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
2004-02-04 13:29 S. Bosscher
@ 2004-02-04 13:49 ` Paul Brook
2004-02-04 14:04 ` Michael Matz
1 sibling, 0 replies; 35+ messages in thread
From: Paul Brook @ 2004-02-04 13:49 UTC (permalink / raw)
To: S. Bosscher, 'kenner@vlsi1.ultra.nyu.edu ',
'paolo.bonzini@polimi.it '
Cc: 'gcc@gcc.gnu.org '
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* RE: What to remove after tree-ssa is merged?
@ 2004-02-04 13:29 S. Bosscher
2004-02-04 13:49 ` Paul Brook
2004-02-04 14:04 ` Michael Matz
0 siblings, 2 replies; 35+ messages in thread
From: S. Bosscher @ 2004-02-04 13:29 UTC (permalink / raw)
To: 'kenner@vlsi1.ultra.nyu.edu ',
'paolo.bonzini@polimi.it '
Cc: 'gcc@gcc.gnu.org '
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: What to remove after tree-ssa is merged?
@ 2004-02-04 12:30 Richard Kenner
0 siblings, 0 replies; 35+ messages in thread
From: Richard Kenner @ 2004-02-04 12:30 UTC (permalink / raw)
To: paolo.bonzini; +Cc: gcc
I remember you also removed PLACEHOLDER_EXPR.
That's required for Ada, so can't be removed.
^ permalink raw reply [flat|nested] 35+ messages in thread
* What to remove after tree-ssa is merged?
2004-02-03 16:54 ` Jan Hubicka
@ 2004-02-03 16:58 ` Paolo Bonzini
0 siblings, 0 replies; 35+ messages in thread
From: Paolo Bonzini @ 2004-02-03 16:58 UTC (permalink / raw)
To: Jan Hubicka; +Cc: gcc
> 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
^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2004-02-05 5:50 UTC | newest]
Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-02-04 15:16 What to remove after tree-ssa is merged? S. Bosscher
-- strict thread matches above, loose matches on Subject: below --
2004-02-04 21:55 Richard Kenner
2004-02-04 21:25 Richard Kenner
2004-02-04 21:51 ` Paul Brook
2004-02-04 21:09 Richard Kenner
2004-02-05 5:32 ` Richard Henderson
2004-02-05 5:50 ` Geert Bosch
2004-02-04 20:55 Richard Kenner
2004-02-04 21:21 ` Paul Brook
2004-02-04 18:43 Richard Kenner
2004-02-04 19:49 ` Paul Brook
2004-02-04 20:15 ` Richard Henderson
2004-02-04 17:54 Richard Kenner
2004-02-04 18:39 ` Paul Brook
2004-02-04 16:14 Richard Kenner
2004-02-04 16:39 ` Michael Matz
2004-02-04 15:49 Richard Kenner
2004-02-04 16:10 ` Michael Matz
2004-02-04 17:25 ` Robert Dewar
2004-02-04 15:21 Richard Kenner
2004-02-04 15:19 Richard Kenner
2004-02-04 15:31 ` Michael Matz
2004-02-04 14:48 Richard Kenner
2004-02-04 14:36 Richard Kenner
2004-02-04 14:44 ` Andrew Pinski
2004-02-04 15:15 ` Michael Matz
2004-02-04 13:52 Richard Kenner
2004-02-04 13:29 S. Bosscher
2004-02-04 13:49 ` Paul Brook
2004-02-04 14:04 ` Michael Matz
2004-02-04 14:19 ` Robert Dewar
2004-02-04 14:31 ` Andrew Pinski
2004-02-04 14:53 ` Robert Dewar
2004-02-04 12:30 Richard Kenner
2004-02-03 16:20 "Documentation by paper" Richard Kenner
2004-02-03 16:54 ` Jan Hubicka
2004-02-03 16:58 ` What to remove after tree-ssa is merged? Paolo Bonzini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).