This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Incomplete TREE_CONSTANT-propagation in build() ?
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