What's on your wish-list (let's leave the GC and other library functionality out of this for now <g>)?

Here's mine:
  - Better floating point code generation
  - Put the tail-recursion optimization back in
  - Omit frame pointers w/ -O switch
  - Improved in-lining (don't arbitrarily exclude functions w/ inout parameters and loops).
  - Auto-finalization.

Dave wrote:
> 
> What's on your wish-list (let's leave the GC and other library functionality out of this for now <g>)?
> 
> Here's mine:
>   - Better floating point code generation
>   - Put the tail-recursion optimization back in
>   - Omit frame pointers w/ -O switch
>   - Improved in-lining (don't arbitrarily exclude functions w/ inout parameters and loops).
>   - Auto-finalization.

The above and:

- Better GC that uses meta data to only track pointers (rather then any number within a specific range).

- Improved efficient library functions (perhaps tango will fix this).

-Joel

janderson wrote:
> Dave wrote:
>>
>> What's on your wish-list (let's leave the GC and other library functionality out of this for now <g>)?
>>
>> Here's mine:
>>   - Better floating point code generation
>>   - Put the tail-recursion optimization back in
>>   - Omit frame pointers w/ -O switch
>>   - Improved in-lining (don't arbitrarily exclude functions w/ inout parameters and loops).
>>   - Auto-finalization.
> 
> The above and:
> 
> - Better GC that uses meta data to only track pointers (rather then any number within a specific range).
> 
> - Improved efficient library functions (perhaps tango will fix this).
> 
> -Joel


Also:

Something like ned-malloc in the standard lib.

-Joel

Dave wrote:
> 
> What's on your wish-list (let's leave the GC and other library functionality out of this for now <g>)?
> 
> Here's mine:
>   - Better floating point code generation
>   - Put the tail-recursion optimization back in
>   - Omit frame pointers w/ -O switch
>   - Improved in-lining (don't arbitrarily exclude functions w/ inout parameters and loops).
>   - Auto-finalization.

Better const folding/handling, local const values are put into the stack frame even if they are never used. (disassemble a run of my bignum template to see this).

preferential inlining of functions with lazy arguments or that take the form:

fn(delegate() dg)
{
	//short code
	dg();
	//short code
}

aggressive de-virtualization of method calls.

BCS wrote:
> Better const folding/handling, local const values are put into the stack frame even if they are never used. (disassemble a run of my bignum template to see this).

On a related note: put global variables (especially constants) into special sections of the object file. That way they can be removed by --gc-sections if not used (or optimized out). Constants are frequently completely folded but still instantiated, this just adds bloat. This isn't really a performance optimization so much as managing its side-effects.

(Also, why is a const int added to .data instead of .rodata?)

> What's on your wish-list (let's leave the GC and other library functionality out of this for now <g>)?

I'd like to see unneccessary copies being optimized away, especially of large structs passed to functions. The workaround

// use inout to pass s by reference, it is not actually modified
void foo(inout LargeStruct s)

is just abusing inout. In my opinion it should be an in parameter and D should detect whether a copy is neccessary or not.

It's not done already, is it?

Christian

Christian Kamm wrote:
>> What's on your wish-list (let's leave the GC and other library functionality out of this for now <g>)?
> 
> I'd like to see unneccessary copies being optimized away, especially of large structs passed to functions. The workaround
> 
> // use inout to pass s by reference, it is not actually modified
> void foo(inout LargeStruct s)
> 
> is just abusing inout. In my opinion it should be an in parameter and D should detect whether a copy is neccessary or not.
> 
> It's not done already, is it?

No, and for a good reason:

foo(LargeStruct s1, LargeStruct s2)
{
  ...
}
...
LargeStruct s;
foo(s, s);

Nobody would enjoy hidden aliasing of s1 and s2.


Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> Christian Kamm wrote:
>>> What's on your wish-list (let's leave the GC and other library functionality out of this for now <g>)?
>>
>> I'd like to see unneccessary copies being optimized away, especially of large structs passed to functions. The workaround
>>
>> // use inout to pass s by reference, it is not actually modified
>> void foo(inout LargeStruct s)
>>
>> is just abusing inout. In my opinion it should be an in parameter and D should detect whether a copy is neccessary or not.
>>
>> It's not done already, is it?
> 
> No, and for a good reason:
> 
> foo(LargeStruct s1, LargeStruct s2)
> {
>   ...
> }
> ...
> LargeStruct s;
> foo(s, s);
> 
> Nobody would enjoy hidden aliasing of s1 and s2.
> 
> 
> Andrei

I'm not really sure why that would be a problem, as long as the compiler has really determined that s1 and s2 aren't being modified by the function.  Maybe you can elaborate?  If it's effectively the same as a const reference, how can the aliasing make a big difference?

But anyway, I don't think it's possible to change way arguments are passed on what the function body does with them.  Say all you have is a .di file with this signature in it:
  void foo(LargeStruct s1, LargeStruct s2);

How is the compiler going to know how to push the parameters on the stack to call foo?

I think it may be possible, however, to establish a rule like "all struct parameters larger than a 'real' are actually passed by reference".  Then it would be up to the compiler to make copies of any modified arguments within the body of the function.

So the code generated for something like

void foo(LargeStruct s1) {
   s1.x = 10;
   ...use s1...
}

would look more like:

void foo(inout LargeStruct s1) {
   LargeStruct s1tmp = s1;
   s1tmp.x = 10;
   ...use s1tmp...
}

I guess you could call that "parameter copy-on-write".

--bb

I believe this is possible.  In particular since D generates its own header files.

I think it would be simple when the compiler knows the intentional (just like inlining works).  Perhaps with a DLL/lib the compiler could mark the functions as constant (or inout) and deal with it differently like you say.

Bill Baxter wrote:

> 
> I'm not really sure why that would be a problem, as long as the compiler has really determined that s1 and s2 aren't being modified by the function.  Maybe you can elaborate?  If it's effectively the same as a const reference, how can the aliasing make a big difference?
> 
> But anyway, I don't think it's possible to change way arguments are passed on what the function body does with them.  Say all you have is a .di file with this signature in it:
>   void foo(LargeStruct s1, LargeStruct s2);
> 
> How is the compiler going to know how to push the parameters on the stack to call foo?
> 
> I think it may be possible, however, to establish a rule like "all struct parameters larger than a 'real' are actually passed by reference".  Then it would be up to the compiler to make copies of any modified arguments within the body of the function.
> 
> So the code generated for something like
> 
> void foo(LargeStruct s1) {
>    s1.x = 10;
>    ...use s1...
> }
> 
> would look more like:
> 
> void foo(inout LargeStruct s1) {
>    LargeStruct s1tmp = s1;
>    s1tmp.x = 10;
>    ...use s1tmp...
> }
> 
> I guess you could call that "parameter copy-on-write".
> 
> --bb
> 

Andrei Alexandrescu (See Website For Email) wrote:
> No, and for a good reason:
> 
> foo(LargeStruct s1, LargeStruct s2)
> {
>   ...
> }
> ...
> LargeStruct s;
> foo(s, s);
> 
> Nobody would enjoy hidden aliasing of s1 and s2.

There's another aliasing case:

LargeStruct s;
foo(s);
... here some other thread modifies s ...

And foo() suddenly has its argument values change unexpectedly.

Value and reference type usages mostly overlap, but they are fundamentally different, and having the compiler switch between the two in some implementation-defined manner (as suggested by others more than once) is not going to work.

If one is needing reference behavior from a struct, seriously consider making it a class instead. Or even just take the address of it and pass the pointer.