Re: [tree-ssa] DCE and aliasing fixes [patch]

[Diego Novillo <dnovillo at redhat dot com>]

On Sun, 02 Feb 2003, Daniel Berlin wrote:

> 
> 
> On Sun, 2 Feb 2003, Diego Novillo wrote:
> 
> > This patch fixes enough bugs in DCE and aliasing that we can now
> > at least enable -ftree-dce when running the testsuite.  We still
> > can't bootstrap with DCE enabled.  We reach stage2 and fail when
> > the stage2 compiler miscompiles genrecog.
> >
> > The main changes are:
> >
> > - When the compiler finds a call to a pure or const function, it
> >   should consider that any pointer passed to the function will be
> >   dereferenced.
> 
> This is incorrect for const functions, as extend.texi says:
> 
> "
> @cindex pointer arguments
> Note that a function that has pointer arguments and examines the data
> pointed to must @emph{not} be declared @code{const}.  Likewise, a
> function that calls a non-@code{const} function usually must not be
> @code{const}.  It does not make sense for a @code{const} function to
> return @code{void}.
> "
> 
Thanks.  I'll have to distinguish between these two cases then.
Going back to the example I posted:

            int foo (int *x)
            {
              return *x;
            }

            int bar()
            {
              i = 10;
              p = &i;
              return foo (p);
            }

We are getting a CONST attribute from flags_from_decl_or_type()
for function foo().  This was causing the dataflow pass to not
consider foo() a clobbering function, and since i = 10 had no
other uses in bar(), it was being killed.

Now that you mention the above paragraph I'm wondering if the
CONST attribute we're getting from flags_from_decl_or_type()
only means that the function makes no definitions to its
arguments.

So, if foo() had been declared as a const function, the compiler
would've been correct to kill the assignment 'i = 10'?


Thanks.  Diego.