[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9542: peval error

From: Ludovic Courtès
Subject: bug#9542: peval error
Date: Sun, 18 Sep 2011 12:00:30 +0200
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux)

Hi Andy,

Andy Wingo <address@hidden> skribis:

> Still, though, the results are not great:


> Here we see that `fold' was inlined once, but to no use.  More code for
> no more speed.

Yes.  OTOH, it was inlined *and* specialized; peval only “inlines”
where’s there’s at least one static argument (known at compile-time), in
which case there’s room for specialization (in this example, *, 1,
zero?, and the anonymous lambdas were propagated/resolved as

In the above example, I agree that we can argue that inlining wasn’t

> Waddell and Dybvig report on similar problems in their inlining paper
> (Fast and Effective Procedure Inlining, IU CS Dept. TR 484).  See
> section 4.4 where they discuss this and similar problems.  We should
> figure out what we can do in these cases; and in the case where we can't
> fully inline a call site, perhaps we should abort the attempt to inline
> it.

Right.  I think we should avoid inlining when recursive calls appear in
the residual code, as mentioned in the referred section.


Now, the current heuristic in peval is to “inline” procedures only at
call sites with static arguments.  Conversely, a general procedure
inlining algorithm like Waddell’s may inline even when there are only
dynamic arguments.  This puts more pressure on the inlining criteria
because there are many more potential inlining opportunities.

I don’t think an optimization heuristic can be optimal in all cases.

So the question is not whether we can find such pathological cases, but
how frequent they are in practice.  So I think we must keep an eye on
the optimized code, like you did, to find out more.

Thanks for your feedback!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]