RE: [sdcc-devel] builtin functions

[Scott D. <sc...@da...>]

On Sun, 18 Nov 2001, Sandeep Dutta wrote:

> Hi Scott,
>
> The major one being run time performance improvement , builtins don't
> actually
> generate function calls but do the code inline.

<snip>

Yep.

>
> We can do further optimizations depending on the nature of the builtin
> function ,
> lets take memcpy as an example again (we know that it does not modify any
> scalar global variable)
> so we can carry global variable dataflow information across builtin
> functions (again
> currently this is not the case.. I'm working on it )...

This is the one that I was thinking about.

>
> Some processor specific stuff can implemented using these functions. for
> example if
> the processor lets say supports BCD arithmetic ... these instructions cannot
> really
> be generated by the compiler without declaring a BCD fundamental data
> type...but can be
> generated using builtin functions ...

I hadn't thought of this one, but it is true.

All of these reasons are true. I'm slowly coming around to believe what's
probably obvious to experienced compiler writers: The more optimization
you do up front the easier it is to optimize. Each stage of the
compilation process removes a little bit of information from the original
code. So by the time you get to the generated assembly it's nearly
impossible for the compiler to determine the original intent. It's kind of
like the "Operator Game" that kids play.

The first two reasons you cite for the benefit of builtins can in theory
be handled by the post code optimizer. For example, the linker can perform
a call tree analysis and inline those functions called only once (or
perhaps twice...). Register analysis could remove redundantly used
registers. But the last case you cite is very difficult to optimize using
the iCode/gen/pCode optimization sequence.

Builtins will be/are a great feature.

Scott