On Thursday, 13 October 2016 at 23:15:00 UTC, David Gileadi wrote:
> On 10/13/16 12:52 PM, Stefan Koch wrote:
>> On Thursday, 13 October 2016 at 19:49:42 UTC, Johan Engelen wrote:
>>> On Thursday, 13 October 2016 at 19:35:08 UTC, Stefan Koch wrote:
>>>>
>>>> Please share your thoughts and tell me what other intrinsic functions
>>>> could/should be added.
>>>
>>> I think the name should be different from "intrinsics", so that it can
>>> also contain functions like "likely-functionptr" / "likely-class"
>>> optimization functions (e.g. the is_likely template from the other
>>> thread).
>>>
>>> -Johan
>>
>> What name would you suggest then ?
>
> As an ignorant bystander I like core.intrinsics, but if not then perhaps core.compilerhints or something to that effect?

core.hints

short and simple

On Friday, 14 October 2016 at 04:44:46 UTC, Patrick Schluter wrote:
>
> core.hints
>
> short and simple

core.hints ?
That sounds to weak.
If I tell the compiler to group function a and function b together and position them as close as possible to each other it damn well better do it.
Because If I went trough the trouble of determining that this has to be done.
I want to use that knowledge.

On Friday, 14 October 2016 at 04:44:46 UTC, Patrick Schluter wrote:
> On Thursday, 13 October 2016 at 23:15:00 UTC, David Gileadi wrote:
>> On 10/13/16 12:52 PM, Stefan Koch wrote:
>>> On Thursday, 13 October 2016 at 19:49:42 UTC, Johan Engelen wrote:
>>>> On Thursday, 13 October 2016 at 19:35:08 UTC, Stefan Koch wrote:
>>>>>
>>>>> Please share your thoughts and tell me what other intrinsic functions
>>>>> could/should be added.
>>>>
>>>> I think the name should be different from "intrinsics", so that it can
>>>> also contain functions like "likely-functionptr" / "likely-class"
>>>> optimization functions (e.g. the is_likely template from the other
>>>> thread).
>>>>
>>>> -Johan
>>>
>>> What name would you suggest then ?
>>
>> As an ignorant bystander I like core.intrinsics, but if not then perhaps core.compilerhints or something to that effect?
>
> core.hints
>
> short and simple

but core.intrinsics would have the advantage that it can be used to put other intrinsics that are not specifically compiler hints (like __builtin___clear_cache from gcc for example).

On 2016-10-14 06:44, Patrick Schluter wrote:

> core.hints
>
> short and simple

I don't see a reason why it would need to be short and simple. Less than 1% of all users would find a need for this.

-- 
/Jacob Carlborg

On Friday, 14 October 2016 at 04:49:30 UTC, Stefan Koch wrote:
> On Friday, 14 October 2016 at 04:44:46 UTC, Patrick Schluter wrote:
>>
>> core.hints
>>
>> short and simple
>
> core.hints ?
> That sounds to weak.
> If I tell the compiler to group function a and function b together and position them as close as possible to each other it damn well better do it.
> Because If I went trough the trouble of determining that this has to be done.
> I want to use that knowledge.

core.code-gen-rules then?

On Friday, 14 October 2016 at 04:50:37 UTC, Patrick Schluter wrote:
>
> but core.intrinsics would have the advantage that it can be used to put other intrinsics that are not specifically compiler hints (like __builtin___clear_cache from gcc for example).

And it has the disadvantage that _only_ compiler intrinsics can be put in it. The function ptr example I gave wouldn't fit.
To me "intrinsic" means "not portable".

On Friday, 14 October 2016 at 04:49:30 UTC, Stefan Koch wrote:
> On Friday, 14 October 2016 at 04:44:46 UTC, Patrick Schluter wrote:
>>
>> core.hints
>>
>> short and simple
>
> core.hints ?
> That sounds to weak.

I like "hints". It's immediately clear that the functions don't do anything and don't change the meaning of your program, they are just hints.

> If I tell the compiler to group function a and function b together and position them as close as possible to each other it damn well better do it.
> Because If I went trough the trouble of determining that this has to be done.
> I want to use that knowledge.

What you want is much more than what triggered this discussion.
I think for grouping functions, you'll have to fight with the linker.

If you tell the compiler to expect "true" for a certain bool expression, it can try to find a better "polarity" of cmp-jmp code. Note that expected values can propagate. If you force it to use one polarity or another, I think very quickly you'll end up having to rewrite your hints when slightly change function control-flow, e.g. by adding an if-statement that makes it more profitable to invert the polarity compared to what it was before.

On 10/14/2016 12:50 AM, Patrick Schluter wrote:
> but core.intrinsics would have the advantage that it can be used to put
> other intrinsics that are not specifically compiler hints (like
> __builtin___clear_cache from gcc for example).

Walter mentioned there are intrinsics in druntime already, and they're grouped by purpose, not by their being intrinsics.

Again: if we figure more of the things to group together with likely and unlikely, a name will emerge.


Andrei

On 10/14/2016 05:24 AM, Johan Engelen wrote:
> I like "hints".

How many other hints are out there? -- Andrei

On Friday, 14 October 2016 at 11:17:55 UTC, Andrei Alexandrescu wrote:
> On 10/14/2016 05:24 AM, Johan Engelen wrote:
>> I like "hints".
>
> How many other hints are out there? -- Andrei

Things that come to mind:
- this value is probably X  (bool, int, pointer)
- this type is probably Y
- this function is likely hot/cold (UDA)
- this data is likely to be accessed soon (_could_ lead to a prefetch)
- this member field is hot/cold (iirc, Class members may be re-ordered) (UDA)