This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Fix gcc.dg/tree-ssa/20030530-2.c
- From: law at redhat dot com
- To: Jason Merrill <jason at redhat dot com>
- Cc: Diego Novillo <dnovillo at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 11 Jun 2003 19:41:12 -0600
- Subject: Re: [tree-ssa] Fix gcc.dg/tree-ssa/20030530-2.c
- Reply-to: law at redhat dot com
In message <firstname.lastname@example.org>, Jason Merrill writes:
>> Also, don't we recognize functions whose calls can be elided if they're
>> called with the same arguments repeatedly? (I forget the technical term
>"pure". Not yet, because of TREE_SIDE_EFFECTS. Perhaps we shouldn't set
>TREE_SIDE_EFFECTS on calls to pure functions.
This appears to be pretty easy. We don't necessarily want to do this
in the front-end since when we compile functions we record certain
meta-data such as const/pure. So if we've compiled function X and
determined it's pure we can use that information when X is called
later in some other function within the same compilation unit.
So what I've done is twiddle the bit in the gimplifier. It's exposed a
A bug when we build the CFG (see thread about gimplifying java, the
same problem has been tickled there). Basically when we have
empty statements at the tail of a LOOP, we lose some edges.
A bug in the tree-inliner -- when we inline a call to a function
with TREE_SIDE_EFFECTS clear, the BIND_EXPR for the inlined
copy also has TREE_SIDE_EFFECTS clear -- which isn't right since
the inlined copy may have interesting side effects once inlined.
operand_equal_p always returned false for CALL_EXPRs. It's pretty
simple to extend it to verify the operands of the CALL_EXPRs