On 10/14/2016 07:51 AM, Johan Engelen wrote:
> 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)

These would be all covered by __builtin_expect or similar.

> - 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)

Any of these present in existing implementations?


Andrei

On Friday, 14 October 2016 at 11:53:55 UTC, Andrei Alexandrescu wrote:
> On 10/14/2016 07:51 AM, Johan Engelen wrote:
>> 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)
>
> These would be all covered by __builtin_expect or similar.

For LLVM, not (yet?) for pointers (there is not builtin for the is_likely template that I posted).

>> - 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)
>
> Any of these present in existing implementations?

I only know about LLVM/LDC.
- type is probably Y: No.  It can be used for devirtualization (similar to the fptr optimization), and I have implemented it in LDC using profiling data (it's not in master).
- function hotness: No, but trivially added.
- data prefetching: Yes.
- member field hotness + reordering: No, but it is easy to imagine how to implement it.

On Friday, 14 October 2016 at 11:53:55 UTC, Andrei Alexandrescu wrote:
> 
> Any of these present in existing implementations?

Perhaps not clear, but my point that the functions should _not do anything_ is important: it is trivial to define default implementations for the functions, without requiring any compiler support. It's just a hint, after all.

On 10/14/2016 08:12 AM, Johan Engelen wrote:
> On Friday, 14 October 2016 at 11:53:55 UTC, Andrei Alexandrescu wrote:
>>
>> Any of these present in existing implementations?
>
> Perhaps not clear, but my point that the functions should _not do
> anything_ is important: it is trivial to define default implementations
> for the functions, without requiring any compiler support. It's just a
> hint, after all.

I was suggesting we find artifacts that exist and map them in runtime, instead of first choosing the name "hints" and then racking our brain on what those could be :o). -- Andrei

On Friday, 14 October 2016 at 11:51:32 UTC, Johan Engelen wrote:
> 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)

- this pointer is aligned to N bytes
- this pointer doesn't alias with this pointer

There are also loop hints:

- this loop has no loop dependency, go wild auto-vectorizer!
- this loop is better unrolled by N

These hints are all dangerous. Manual prefetching, manual branch hints, forced unrolling count: I've seen those 3 hints reduce performance by being worse than the processor/compiler.

On Friday, 14 October 2016 at 12:55:17 UTC, Guillaume Piolat wrote:
> 
> - this pointer is aligned to N bytes
> - this pointer doesn't alias with this pointer

Do you mean these as "just a hint, should not generate invalid code if not true" or as "a certainty, allowed to generate invalid code if not true" ?
(my intent is the former)

On Friday, 14 October 2016 at 13:07:10 UTC, Johan Engelen wrote:
> On Friday, 14 October 2016 at 12:55:17 UTC, Guillaume Piolat wrote:
>> 
>> - this pointer is aligned to N bytes
>> - this pointer doesn't alias with this pointer
>
> Do you mean these as "just a hint, should not generate invalid code if not true" or as "a certainty, allowed to generate invalid code if not true" ?
> (my intent is the former)

Not a compiler engineer, but it seems to me the compiler should have the last word about this, and not generate invalid code. This rules out both of these hints I guess.

On Friday, 14 October 2016 at 13:07:10 UTC, Johan Engelen wrote:
> On Friday, 14 October 2016 at 12:55:17 UTC, Guillaume Piolat wrote:
>> 
>> - this pointer is aligned to N bytes
>> - this pointer doesn't alias with this pointer
>
> Do you mean these as "just a hint, should not generate invalid code if not true" or as "a certainty, allowed to generate invalid code if not true" ?

For alignment/aliasing restrictions to be really beneficial, you have to be able to assume they hold, though. — David

On Friday, 14 October 2016 at 15:42:22 UTC, David Nadlinger wrote:
> On Friday, 14 October 2016 at 13:07:10 UTC, Johan Engelen wrote:
>> On Friday, 14 October 2016 at 12:55:17 UTC, Guillaume Piolat wrote:
>>> 
>>> - this pointer is aligned to N bytes
>>> - this pointer doesn't alias with this pointer
>>
>> Do you mean these as "just a hint, should not generate invalid code if not true" or as "a certainty, allowed to generate invalid code if not true" ?
>
> For alignment/aliasing restrictions to be really beneficial, you have to be able to assume they hold, though. — David

You could turn "hints" that can possibly create invalid code automatically into assertions in non-release builds. Or let the user add an assertion and use the "turn assert() into assume()" idea for release builds.

On Saturday, 15 October 2016 at 10:17:09 UTC, Matthias Bentrup wrote:
>
> You could turn "hints" that can possibly create invalid code automatically into assertions in non-release builds. Or let the user add an assertion and use the "turn assert() into assume()" idea for release builds.

I cannot think of any hints the would produce incorrect code.
Hints may create terribly inefficient code if they are wrong.
But incorrect code ... no examples come to mind.