This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: More on c-gimplify.c:gimplify_decl_stmt
- From: Richard Henderson <rth at redhat dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 6 Jun 2004 18:24:37 -0700
- Subject: Re: More on c-gimplify.c:gimplify_decl_stmt
- References: <10406062338.AA03137@vlsi1.ultra.nyu.edu>
On Sun, Jun 06, 2004 at 07:38:17PM -0400, Richard Kenner wrote:
> That's why my initial feeling is that the tree optimizers should *not*
> attempt to optimize anything related to the type fields (sizes and
> positions). They're constants and don't need optimization. It seems to me
> that putting them into the computation just makes things more complex.
They are most certainly NOT constant. If they were constants, they'd
be INTEGER_CST objects. And they ABSOLUTELY POSITIVELY do need to be
visible to the optimizers. Failure to do so results in wrong answers,
not some sort of lack of optimization.
We started out with an implicitly referenced variable feature on
tree-ssa branch and it caused no end of problems. It's gone now,
and it won't return.
> However, we need that information for aliasing and loop information.
I think we have all we need for aliasing and loop information, actually.
We have numbers that say how far we are from the beginning of the object,
and what the alignment is. What more is there?
> Another problem with doing this early is that you can't scalarize fields that
> are at variable offsets and I see no reason to exclude that.
Haha. Early or late, these objects are at variable offsets. That
is way outside any scalarization I ever plan to implement.
If someone else wanted to tackle it some day, I don't see that
they'd have lost any information except for the name of the field.
Which is basically irrelevant.
r~