Incomplete TREE_CONSTANT-propagation in build() ?

[Ziemowit Laski]

On 4 Nov, 2003, at 16.09, Gabriel Dos Reis wrote:

> Ziemowit Laski <zlaski@apple.com> writes:
>
> [...]
>
> | > | Thing is, the front-end has no way of knowing the intended use of
> | > | something
> | > | like '(1, 2, 3, 4)'; it all depends on what that compound 
> expression
> | > | is eventually
> | > | bound to.
> | >
> | > I hear you, but "(1, 2, 3, 4)" as a compound expression a bit
> | > contorted and I'm really worried about tweaking the front-end into
> | > believeing the contrary.  On the other hand, it is an
> | > expression-list  and the front-end already has knowledge of
> | > expression-lists used as iniatializer.
> |
> | I'm not sure what you mean by 'contorted' here.  To handle '(1, 2, 3,
> | 4)'
> | vector initializer constants, all I really need (aside from their 
> being
> | TREE_CONSTANTs :-) ) is to _defer_ the folding of constant compound
> | expressions,
> | until said expressions get bound.  So, '(1, 2, 3, 4)' simply survives
> | a bit
> | longer.  When it is time to bind it, we check if it is being bound 
> to a
> | VECTOR_TYPE.  If yes, it is converted to a VECTOR_CST; if no, it is
> | finally
> | folded to '4'.
>
> I understand that.  And that is probably roughly how I would implement
> it (except for the use of COMPOUND_EXPR).  My use of "contorted" here
> refers to the fact that a TREE_LIST is not being used for that job.

I guess I'm still not clear on how you'd want me to use TREE_LISTs in 
this
particular context.  At present, both the C and C++ front-ends will turn
'(1, 2, 3, 4)' into COMPOUND_EXPRs.  The essence of my approach is that
the folding of these COMPOUND_EXPRs has to be deferred only long enough
to determine if they should be VECTOR_CSTs instead.  (In C++, it turns
out that the COMPOUND_EXPRs survive long enough already, so no further
deferrals are needed.)

Where does your TREE_LIST idea fit in?  Are you suggesting that the C 
and
C++ parsers turn comma expressions into TREE_LISTs _instead of_
COMPOUND_EXPRs, and then turn said TREE_LISTs into either COMPOUND_EXPRs
or VECTOR_CSTs later on?  This is the only interpretation of your 
TREE_LIST
suggestion that I could come up with.  I suppose it is doable, but I 
fail
to see what it buys you aside from an increased memory footprint and
compile time. :-(

>
> | > Anyway, I believe it is too late for you to revise your design 
> choice?
> |
> | Too late given which constraints?  If you mean too late to move away
> | from
> | the '(1, 2, 3, 4)' syntax, then yes. :-(
>
> I was not commenting on the syntax -- which I guessed you did not
> much choice for.  My comment, again, concerns your insistance on using
> COMPOUND_EXPR instead of a TREE_LIST.
>
> | I definitely prefer Aldy's
> | '{1, 2, 3, 4}' approach.  Alas, we do not have a choice in the 
> matter.
> |
> | > (Certainly, in the C++ front-end you can tell when it is an
> | > expression-list and when it is a compound expresssion).
> |
> | Not very easily.  The vector constants may be nested inside more
> | complicated initializers (say, for structs or arrays), which 
> themselves
> | may undergo "reshaping".  The only way to know for sure is to wait 
> until
> | the initializer element actually gets bound to something.
>
> I don't understand how that precludes the use of a TREE_LIST.  Look at
> how cp_parser_parenthesized_expression_list is used throughout the C++
> parser.  For example, the C++ fornt-end implements initializers in
> terms of an expression-list (a TREE_LIST) instead of a COMPOUND_EXPR.
> That looks to me as the  right thing to do.  Please, consider having a
> look at like.
> You can even be notified whether all sub-expressions are constant
> expressions.
>
> [...]
>
> | > | If the COUPOUND_EXPRs are not marked TREE_CONSTANT, then I have 
> to
> | > | selectively
> | > | rediscover their TREE_CONSTANT-ness throughout the C and C++
> | > | front-ends.  This
> | > | is just horrible, error-prone engineering.  Why can't 
> COMPOUND_EXPRs
> | > | just
> | > | be marked TREE_CONSTANT to begin with? :-)
> | >
> | > given the clarification you make above, I would certainly not 
> object
> | > if the changed is made with appropriate clear comments.
> |
> | Ok, thanks.  Do you think I should offer a one-line patch for tree.c
> | (assuming all tests pass, of course)?
>
> Given that this will have an interaction with the C++ front-end
> (meaning that the C++ front-end will have to support it) I would
> really encourage you to give another try to expression-list as a
> TREE_LIST.

I don't follow you here; the C++ front-end also uses COMPOUND_EXPR for 
comma
expressions; look at build_x_compound_expr().

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477