Jonathan M Davis:
> They probably aren't there because
> ...

In Bugzilla there are some pure-related bugs (3833, 3086/3831, maybe 4505) that I think need that attribute in the mangled string. But as usual I may be wrong, and other ways to solve those problems may be invented.

Bye,
bearophile

On 2010-08-25 02:38, bearophile wrote:
> Jonathan M Davis:
>> They probably aren't there because
>> ...
>
> In Bugzilla there are some pure-related bugs (3833, 3086/3831, maybe 4505) that I think need that attribute in the mangled string. But as usual I may be wrong, and other ways to solve those problems may be invented.
>
> Bye,
> bearophile

According to the ABI pure should already be in the mangled name (don't know if dmd follows that though). The mangled form looks like this:

FuncAttrPure:
    Na

-- 
/Jacob Carlborg

Jacob Carlborg:
> According to the ABI pure should already be in the mangled name (don't know if dmd follows that though). The mangled form looks like this:
> 
> FuncAttrPure:
>      Na

Yes, it's there:

import std.c.stdio: printf;
int function1(int x) {
    return x * 2;
}
pure int function2(int x) {
    return x * 2;
}
void main() {
    printf("%d\n", function1(10));
    printf("%d\n", function2(10));
}


_D5test29function1FiZi	comdat
		enter	4,0
		add	EAX,EAX
		leave
		ret

_D5test29function2FNaiZi	comdat
	assume	CS:_D5test29function2FNaiZi
		enter	4,0
		add	EAX,EAX
		leave
		ret

Bye,
bearophile

On Tue, 24 Aug 2010 18:00:32 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>> Through some more work with printf, I have to agree with bearophile, this lookup function is horrid.
>
> It is now, but when it was originally written (maybe as long as 20 years ago) there were only a few strings in the table, and it was fine. It's just outlived its design. Clearly, it should now be a hash table.
>
> Just goes to show how useful a profiler is.

Yes, I'm glad you pushed me to do it.  Looking forward to the fix.

-Steve

On Tue, 24 Aug 2010 18:00:30 -0400, Simen kjaeraas <simen.kjaras@gmail.com> wrote:

> On Tue, 24 Aug 2010 23:53:44 +0200, Jonathan M Davis <jmdavisprog@gmail.com> wrote:
>
>> On Tuesday, August 24, 2010 14:37:09 bearophile wrote:
>>> Steven Schveighoffer:
>>> > For example, foo(HashSet!int hs) inside the module testme becomes:
>>> > _D6testme3fooFC12dcollections7HashSet14__T7HashSetTiZ7HashSetZv
>>>
>>> And I think some more things needs to be added to that string, like a
>>> representation for the pure attribute, etc.
>>>
>>> Bye,
>>> bearophile
>>
>> They probably aren't there because
>>
>> 1. They have nothing to do with overrideability.
>>
>> 2. They have nothing to do with C linking.
>>
>> Presumably, dmd deals with those attributes at the appropriate time and then
>> doesn't bother putting them in the symbol table because they're not relevant any
>> more (or if they are relevant, it has other ways of getting at them). If they
>> were actually necessary in the symbol name, they'd be there. If they aren't
>> necessary, why bother putting them in there, making the symbol names even
>> longer?
>
> Pure might be worth stuffing in the symbol name, as the compiler may
> optimize things differently for pure vs. non-pure(dirty?) code.
> E.g. the result of a large, pure function that takes a while to compute
> might be cached to prevent calling it twice.

These are decisions made at the compilation stage, not the linking stage.  LDC I think does some link optimization, so it might make sense there, but I'm not sure.

-Steve

Steven Schveighoffer <schveiguy@yahoo.com> wrote:

>> Pure might be worth stuffing in the symbol name, as the compiler may
>> optimize things differently for pure vs. non-pure(dirty?) code.
>> E.g. the result of a large, pure function that takes a while to compute
>> might be cached to prevent calling it twice.
>
> These are decisions made at the compilation stage, not the linking stage.

Absolutely. Now, you compile your module that uses a pure function foo in
another module, and the above optimization is used. Later, that module is
changed, and foo is changed to depend on some global state, and is thus
no longer pure. After compiling this one module, you link your project,
and the cached value is wrong, and boom! Nasal demons.

-- 
Simen

On Wednesday, August 25, 2010 00:42:51 Jacob Carlborg wrote:
> On 2010-08-25 02:38, bearophile wrote:
> > Jonathan M Davis:
> >> They probably aren't there because
> >> ...
> > 
> > In Bugzilla there are some pure-related bugs (3833, 3086/3831, maybe 4505) that I think need that attribute in the mangled string. But as usual I may be wrong, and other ways to solve those problems may be invented.
> > 
> > Bye,
> > bearophile
> 
> According to the ABI pure should already be in the mangled name (don't know if dmd follows that though). The mangled form looks like this:
> 
> FuncAttrPure:
>      Na

So, sodium is pure huh. :)

- Jonathan M Davis

On 26/08/10 02:10, Jonathan M Davis wrote:
> On Wednesday, August 25, 2010 00:42:51 Jacob Carlborg wrote:
>> On 2010-08-25 02:38, bearophile wrote:
>>> Jonathan M Davis:
>>>> They probably aren't there because
>>>> ...
>>>
>>> In Bugzilla there are some pure-related bugs (3833, 3086/3831, maybe
>>> 4505) that I think need that attribute in the mangled string. But as
>>> usual I may be wrong, and other ways to solve those problems may be
>>> invented.
>>>
>>> Bye,
>>> bearophile
>>
>> According to the ABI pure should already be in the mangled name (don't
>> know if dmd follows that though). The mangled form looks like this:
>>
>> FuncAttrPure:
>>       Na
>
> So, sodium is pure huh. :)
>
> - Jonathan M Davis

And natrium also?  :-)

Justin Johansson <no@spam.com> wrote:
>>> FuncAttrPure:
>>>       Na
>>
>> So, sodium is pure huh. :)
>>
>> - Jonathan M Davis
>
> And natrium also?  :-)

Natrium and sodium are the same.

-- 
Simen

On Wed, 25 Aug 2010 11:36:24 -0400, Simen kjaeraas <simen.kjaras@gmail.com> wrote:

> Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>
>>> Pure might be worth stuffing in the symbol name, as the compiler may
>>> optimize things differently for pure vs. non-pure(dirty?) code.
>>> E.g. the result of a large, pure function that takes a while to compute
>>> might be cached to prevent calling it twice.
>>
>> These are decisions made at the compilation stage, not the linking stage.
>
> Absolutely. Now, you compile your module that uses a pure function foo in
> another module, and the above optimization is used. Later, that module is
> changed, and foo is changed to depend on some global state, and is thus
> no longer pure. After compiling this one module, you link your project,
> and the cached value is wrong, and boom! Nasal demons.

You could say the same about just about any function.  Changing implementation can be a bad source of stale object errors, I've had it happen many times in C++ without pure involved at all.  Moral is, always recompile everything :)

My point is just that name mangling was done to allow overloaded functions of the same name be linked by a linker who doesn't understand overloading.  If pure functions cannot be overloaded on purity alone, then there's no reason to mangle purity into the symbol.

But it's a moot point, since purity *is* mangled into the symbol name.

-Steve