From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25339 invoked by alias); 4 Feb 2004 15:49:27 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 25331 invoked from network); 4 Feb 2004 15:49:26 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sources.redhat.com with SMTP; 4 Feb 2004 15:49:26 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA01170; Wed, 4 Feb 04 10:51:59 EST Date: Wed, 04 Feb 2004 15:49:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10402041551.AA01170@vlsi1.ultra.nyu.edu> To: matz@suse.de Subject: Re: What to remove after tree-ssa is merged? Cc: gcc@gcc.gnu.org X-SW-Source: 2004-02/txt/msg00265.txt.bz2 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.