Re: TREE_UNCHANGING?

[Daniel Berlin <dberlin at dberlin dot org>]

On Wed, 8 May 2002, Daniel Berlin wrote:

> On Thu, 9 May 2002, Jason Merrill wrote:
> 
> > >>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:
> > 
> > > I would like to be able to tell the backend that the vtable for a class
> > > object will never change, regardless of anything else we might or might not
> > > know about that object, so we can hoist vtable lookups out of loops.
> > 
> > Tangent:
> > 
> > While setting TREE_CONSTANT does the trick for normal virtual function
> > calls, it isn't enough for calls through a pointer-to-member function.
> > This turns out to be because the loop optimizer isn't clever enough to
> > hoist the complicated code for resolving a pmf, which involves a test and
> > jump.
> > 
> > I've whipped up a C analog below; this testcase takes 50% longer to run
> > with -O2 than with -O2 -fno-inline, because of the const function
> > optimization.  If we inline, we lose that information; there ought to be a
> > way to express the same thing for inlined/open-coded routines.
> > 
> > I thought about using a libcall block, but that seems to be specific to
> > calls.  Any reason not to use it for an arbitrary block of code with
> > defined inputs and output?  <hack, hack> Nope, doesn't work.  loop still
> > looks at the individual insns, and doesn't think it can move some of the
> > internal sets.
> > 
> > Does the AST optimizer branch support anything like this?
> 
> It'll simplify it so that it might be able to hoist it.
> That is, it *would*, except expand_call_inline produces invalid statement 
> expressions.
> 
> The c-tree docs say "The @code{STMT_EXPR_STMT} gives the statement
> contained in the expression; this is always a @code{COMPOUND_STMT}."
> 
> It forgets the compound statement.
> So we never notice it returns a value in simplification, and end  up 
> aborting eventually because something tries to use the return value, when 
> it's now a null tree (since we never stored it anywhere, thinking it 
> wasn't used).
> 
> The stmt_expr inlining generates:
<snip>

After fixing the inlining problem so it generates a compound_stmt around 
the stmt_expr it makes, and improving the c-pretty-printer so it makes 
nice printouts of pfn related stuff, I can answer your question.

The answer is "no, not yet".

If the function has the const attribute, we basically ignore this 
when remapping things around and copying parameters.
Shouldn't we be able to take advantage of this and set 
TREE_CONSTANT/TREE_READONLY on some of the parm_decls we remap?
Or at least, on the return value's statement?
Or *something*?

Doing some of these makes it *almost* hoist the mems in the address 
calculation. They do get marked as unchanging, etc.

(insn 4 90 6 (set (reg/v/u/f:SI 58)
        (mem/u/f:SI (reg/f:SI 16 argp) [2 ap+0 S4 A32])) 45 {*movsi_1} 
(nil)
    (expr_list:REG_EQUIV (mem/u/f:SI (reg/f:SI 16 argp) [2 ap+0 S4 A32])
        (nil)))


(insn 43 92 45 (set (reg:SI 69)
        (mem/s:SI (reg/v/u/f:SI 58) [8 <variable>.vptr+0 S4 A32])) -1 
(nil)
    (nil))


But loop decides they can trap.


BTW, according to the manual, your function isn't supposed to be declared 
const.
In fact, it emphasizes it:
@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}.