GSOC Linker project

[Steven Schveighoffer]

On Mon, 07 May 2012 07:41:43 -0400, Alex Rønne Petersen  
<xtzgzorex at gmail.com> wrote:

> On 07-05-2012 13:21, Steven Schveighoffer wrote:
>> On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen
>> <xtzgzorex at gmail.com> wrote:
>>
>>> Purity inference won't happen either way. Purity is part of your API
>>> and also meant to help you reason about your code. If the compiler
>>> just infers purity in a function and you later change the
>>> implementation so it's no longer pure, you break your users' code.
>>> Also, purity would no longer help you reason about your code if it's
>>> not explicit.
>>
>> It can be pure for the purposes of optimization without affecting code
>> whatsoever. Inferred purity can be marked separately from explicit
>> purity, and explicitly pure functions would not be allowed to call
>> implicitly pure functions.
>>
>> -Steve
>
> But that kind of inferred purity is something a compiler back end cares  
> about, not something the language should have to care about at all. In  
> practice, most compilers *do* analyze all functions for possible  
> side-effects and use that information where applicable.

It affects how callers code will be generated.

If I have a function

int foo(int x);

and I have another function which calls foo like:

int y = foo(x) + foo(x);

Then the optimization is applied to whatever function this exists in.  If  
the source isn't available for foo, the compiler cannot make this  
optimization.

I have no idea if this is a back-end or front-end issue.  I'm not a  
compiler writer.  But I do understand that the compiler needs extra  
information in the signature to determine if it can make this optimization.

-Steve