This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] PR14841 and PR15838
- From: Steven Bosscher <stevenb at suse dot de>
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 31 Aug 2004 18:55:34 +0200
- Subject: Re: [PATCH] PR14841 and PR15838
- Organization: SUSE Labs
- References: <10408311643.AA07348@vlsi1.ultra.nyu.edu>
On Tuesday 31 August 2004 18:43, Richard Kenner wrote:
> Not really. This optimization is not done by fold-const.c.
> Why else do you think it didn't work before? ;-)
>
> I don't know, but it's there for the component case, or at least code
> that purports to be that:
>
> case COMPONENT_REF:
> if (TREE_CODE (arg0) == CONSTRUCTOR
> && ! type_contains_placeholder_p (TREE_TYPE (arg0)))
> {
> tree m = purpose_member (arg1, CONSTRUCTOR_ELTS (arg0));
> if (m)
> return TREE_VALUE (m);
> }
> return t;
>
> We cannot do this in fold-const.c, because there we can't tell if we
> had just "a = b[c];" or perhaps "a = &b[c];". That's why I've put it
> in tree-ssa-ccp.c.
>
> If this is just the case where B is a CONSTRUCTOR, I don't understand
> the issue you are raising.
What do you mean "B is a constructor". Of course B is not a constructor,
it is a const variable with an initializer.
struct a { int i; };
static const struct a b = { 1 };
int foo1 (void){ return b.i; } /* Can fold. */
void *foop (void){ return &b.i; } /* Can not fold. */
static const int banana[] = { 0, 1, 2, 3 };
int fruit (void) { return banana[2]; } /* Can fold. */
void *fruitp (void) { return &banana[2]; } /* Can not fold. */
The cases we can fold are not done in fold-const.c because it can't
tell that "b.i" or "banana[2]" is the whole expression, not part of
an ADDR_EXPR or something similar.
When would B ever be only a CONSTRUCTOR?
Gr.
Steven