This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fix processing of ADDR_EXPR in get_expr_operands
- From: Diego Novillo <dnovillo at redhat dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 30 Jul 2004 09:54:06 -0400
- Subject: Re: Fix processing of ADDR_EXPR in get_expr_operands
- Organization: Red Hat Canada
- References: <10407301327.AA17310@vlsi1.ultra.nyu.edu>
On Fri, 2004-07-30 at 09:27, Richard Kenner wrote:
> No. It is not a bug. I don't know how else to tell you the same
> thing. Address constness is checked with TREE_INVARIANT. The address
> of a variable may be invariant in one invocation to a function, but have
> different values from call to call.
>
> The two mean two different thing: "invariant" means it won't change during
> the execution of the function while "constant" means it won't change *at all*.
>
I feel like I'm talking to myself here. Yes, that's exactly what it
means and that's exactly what I've been saying all this time.
> I can easily see cases where the first is what's wanted and where the second
> is what's wanted. It may well be that in that particular case, "invariant"
> is the wanted property, but I don't accept that that's *always* the case.
>
For address constants? Yes, that's always the case. CONSTANT is a
superset of INVARIANT. In an intra-procedural setting, we care for
invariant addresses, we don't care if they are constant or not.
> Yes. Overflow.
>
> Why do we care about overflow? If an addressing computation overflows, it's
> still a constant!
>
No. That's for real constants. I was describing what
is_gimple_min_invariant does. Check the code out.
Diego.