> To make this code specialize two things are needed:
>
> 1. Infer more specific types for (recursive) functions.
>
> 2. Prove that a function is always called with correct arguments.
>
> If we can do this then we can effectively re-walk the function with the
> arguments assumed to be of the correct types. This should cause all
> calls to be specialized.
>
> Feature 1. is hard and lots of work, but doable. This needs for example
> adding support for unifying 2 type variables.
>
> Feature 2. is probably not that hard for the simple cases like above.
> And handling the simple cases might be enough.
>
> [...]
> >
> > That's only slower due to a C_trace call. With -d0 it produces
> > more or less identical code with -O3.
>
> I do get a nice speedup with -O3 if I annotate the sum inside the fp+
> call: (the float sum).
I was about to suggest that, there is also "assume", IIRC.
Doing global flow-analysis is a completely different problem from
what the scrutinizer currently implements, and it was never intended
to do such an analysis. This is really, really hard, just as megane
says. There is also the question whether all the additional complexity
needed for this is worth the effort (we are still talking about a micro-
benchmark here), and the scrutinizer is already terribly complex.
To suggestion 2: one could track calls to unexported ("block-mode")
functions, and so build a set of possible argument types. But this
can not be done without some form of declaration or compile-mode,
otherwise debugging cases where the things are "optimized" while
procedures escape (using low-level APIs or just because of wrong
assumptions by the user) will drive you insane.
felix
felix
_______________________________________________
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
