GSOC Linker project

[Andrew Wiley]

On Mon, May 7, 2012 at 8:42 AM, Steven Schveighoffer <schveiguy at yahoo.com>wrote:

> On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen <
> xtzgzorex at gmail.com> wrote:
>
>  On 07-05-2012 14:50, Steven Schveighoffer wrote:
>>
>>> 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.
>>>
>>>
>> OK, point taken; didn't consider that. But in the first place, for
>> inference of purity to work, the source would have to be available. Then,
>> that inferred property has to be propagated somehow so that the compiler
>> can make use of it when linking to the code as a library...
>>
>
> That's exactly what storing the interface in the object file does.  You
> don't need the source because the object file contains the compiler's
> interpretation of the source, and any inferred properties it has discovered.
>

Putting inferred purity into an object file sounds like a bad idea. It's
not hard to imagine this scenario:
-function foo in libSomething is inferred as pure (but not declared pure by
the author)
-exeSomethingElse is compiled to use libSomething, and the compiler takes
advantage of purity optimizations when calling foo
-libSomething is recompiled and foo is no longer pure, and exeSomethingElse
silently breaks

Purity inference is fine for templates (because recompiling the library
won't change the generated template code in an executable that depends on
it), but in all other cases, the API needs to be exactly what the author
declared it to be, or strange things will happen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120507/5b9e3fe1/attachment-0001.html>