Re: Incomplete TREE_CONSTANT-propagation in build() ?

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

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.

| > 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. 

Of course, you might independently propose the patch for tree.c given
Joseph's comment.

-- Gaby