February 17, 2014
Walter Bright:

> On 2/13/2014 4:42 PM, Adam D. Ruppe wrote:
>> If I'm not missing anything, these three changes would let us completely define
>> (or not define) type info in the library without breaking anything we have now!
>
> It's a good idea worth exploring.

And at this stage of the D life it's acceptable to even have tiny breaking changes, if they give back significant good things. A purely library implementation of TypeInfo could bring some advantages.

Bye,
bearophile
February 17, 2014
On Friday, 14 February 2014 at 20:05:53 UTC, Rainer Schuetze wrote:

>
> The only drawback I see is that it makes compilation a bit slower and pollutes object files with code just executed during CTFE.

Currently, the bloat can be reduced like this:

void foo()
{
  if (__ctfe)
  {
    // function body
  }
  else
    asm { naked; }
}

But that's an awful dangerous hack. A better solution is needed.



February 17, 2014
On Monday, 17 February 2014 at 09:33:01 UTC, Max Samukha wrote:
> But that's an awful dangerous hack. A better solution is needed.

I have been thinking about addition of something like `pragma(nocodegen)` to the language. Should be simple to implement and can fix some of most crazy bloat issues in libraries until something like whole-program optimization can become practical reality.

It will help not only CTFE - for example, all template constraints and all template argument list metaprogramming facilities can be annotated with it in Phobos.

Walter, would you approve something like this?
February 17, 2014
If a function is only used for CTFE, compiler can elide its codegen. It's in the scope of optimization.

Kenji Hara


2014-02-17 22:48 GMT+09:00 Dicebot <public@dicebot.lv>:

> On Monday, 17 February 2014 at 09:33:01 UTC, Max Samukha wrote:
>
>> But that's an awful dangerous hack. A better solution is needed.
>>
>
> I have been thinking about addition of something like `pragma(nocodegen)` to the language. Should be simple to implement and can fix some of most crazy bloat issues in libraries until something like whole-program optimization can become practical reality.
>
> It will help not only CTFE - for example, all template constraints and all template argument list metaprogramming facilities can be annotated with it in Phobos.
>
> Walter, would you approve something like this?
>


February 17, 2014
On Monday, 17 February 2014 at 14:51:20 UTC, Kenji Hara wrote:
> If a function is only used for CTFE, compiler can elide its codegen. It's
> in the scope of optimization.

It can't know for sure it without some sort of WPO / LTO - and those won't happen any time soon. I propose a simple workaround that can be done right now (it can be optional compiler-specific addition)
February 17, 2014
2014-02-18 0:48 GMT+09:00 Dicebot <public@dicebot.lv>:

> On Monday, 17 February 2014 at 14:51:20 UTC, Kenji Hara wrote:
>
>> If a function is only used for CTFE, compiler can elide its codegen. It's in the scope of optimization.
>>
>
> It can't know for sure it without some sort of WPO / LTO - and those won't happen any time soon. I propose a simple workaround that can be done right now (it can be optional compiler-specific addition)
>

In some case it would be possible without WPO/LTO:

- Immediately called lambdas

  enum x = (){ return some_sort_ctfe_calculartions; };   // lambda codegen
is unnecessary.

- modue private functions

  module a;
  private string foo() { ... }
  enum x = foo();
  // Compiler can elide codegen for 'foo', if other declarations
  // in module a don't use it for runtime code.

Kenji Hara


February 17, 2014
17-Feb-2014 17:48, Dicebot пишет:
> On Monday, 17 February 2014 at 09:33:01 UTC, Max Samukha wrote:
>> But that's an awful dangerous hack. A better solution is needed.
>
> I have been thinking about addition of something like
> `pragma(nocodegen)` to the language. Should be simple to implement and
> can fix some of most crazy bloat issues in libraries until something
> like whole-program optimization can become practical reality.
>

Like it!


-- 
Dmitry Olshansky
February 17, 2014
On Monday, 17 February 2014 at 16:01:50 UTC, Kenji Hara wrote:
> - Immediately called lambdas
>
>   enum x = (){ return some_sort_ctfe_calculartions; };   // lambda codegen
> is unnecessary.

True but this is only one of many cases.

> - modue private functions
>
>   module a;
>   private string foo() { ... }
>   enum x = foo();
>   // Compiler can elide codegen for 'foo', if other declarations
>   // in module a don't use it for runtime code.

It is not that simple. Other declarations can also be templates or CTFE functions (but public) - compiler can't know if those will be used in runtime codegen in other modules. And being conservative will make optimization much less useful.

This is exactly why I am referencing WPO/LTO - doing this is plain optimization is theoretically possible but is huge effort to implement in somewhat reliable way. I'd like to have something simple that can help right now and turned into no-op later once compiler becomes clever enough.
February 17, 2014
Am Tue, 18 Feb 2014 01:01:18 +0900
schrieb Kenji Hara <k.hara.pg@gmail.com>:

> In some case it would be possible without WPO/LTO:
> 
> - Immediately called lambdas
> 
>   enum x = (){ return some_sort_ctfe_calculartions; };   // lambda
> codegen is unnecessary.
> 
> - modue private functions
> 
>   module a;
>   private string foo() { ... }
>   enum x = foo();
>   // Compiler can elide codegen for 'foo', if other declarations
>   // in module a don't use it for runtime code.
> 
> Kenji Hara
> 

- Template instances of any module if the instance is only used in CTFE
February 17, 2014
On 2014-02-17 17:01, Kenji Hara wrote:

> - modue private functions
>
>    module a;
>    private string foo() { ... }
>    enum x = foo();
>    // Compiler can elide codegen for 'foo', if other declarations
>    // in module a don't use it for runtime code.

Private functions can be called from other modules via function pointers.

-- 
/Jacob Carlborg