Incomplete TREE_CONSTANT-propagation in build() ?

[Ziemowit Laski]

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

> Ziemowit Laski <zlaski@apple.com> writes:
>
> | On 4 Nov, 2003, at 12.46, Gabriel Dos Reis wrote:
> |
> | > Ziemowit Laski <zlaski@apple.com> writes:
> | >
> | > | On 4 Nov, 2003, at 12.23, Gabriel Dos Reis wrote:
> | > |
> | > | > Ziemowit Laski <zlaski@apple.com> writes:
> | > | >
> | > | > | P.S.  For the morbidly curious, I'm working on Motorola-style
> | > AltiVec
> | > | > | support in the 3.4 tree, and I really need compound
> | > expressions like
> | > | > | '(1, 2, 3, 4)' to be marked TREE_CONSTANT. :-)
> | > | >
> | > | > Why don't you use VECTOR_CST?
> | > |
> | > | I am, but before they become VECTOR_CSTs, they are COMPOUND_EXPRs
> | > (due
> | > | to the parenthesized Motorola notation).
> | >
> | > OK, understood.  However, I would think that a TREE_LIST would be 
> much
> | > more appropriate: it really is a list of constant expression 
> instead
> | > of a sequence of expressions, evaluated and discarded  except the 
> last
> | > one.  It would be really helpful if the front-ends could be made 
> much
> | > more consistent in that area.
> |
> | 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'.

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

>
> |  So I can't really decide a priori if I should use
> | TREE_LISTs or not.
> | >
> | > | > A compound expression is NEVER a constant expression EVEN if 
> its
> | > | > operands are all constant expressions.
> | > |
> | > | Why not?
> | >
> | > I have no idea of the raionale behond "that is what the standard 
> says".
> |
> | Well, I was thinking in terms of gcc internals rather than standards.
> | (I neither object to nor understand what the standars says in this 
> case,
> | but that's an orthogonal matter.)
>
> OK, thanks for the clarification.
>
> | 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)?

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