• Stefan Koch (13/13) Oct 13 2016 Hi,
• Johan Engelen (6/8) Oct 13 2016 I think the name should be different from "intrinsics", so that
• Stefan Koch (5/14) Oct 13 2016 What name would you suggest then ?
• Johan Engelen (3/6) Oct 13 2016 It's at the bottom of druntime/src/ldc/intrinsics.di (note the
• Stefan Koch (6/12) Oct 13 2016 I saw that one, but I cannot find the place where ldc checks for
• Johan Engelen (6/7) Oct 13 2016 Yeah, that's the problem isn't it... :(
• Dominikus Dittes Scherkl (2/17) Oct 13 2016 how about "fuzzylogic"?
• Stefan Koch (16/34) Oct 13 2016 It has nothing todo with fuzzy logic.
• Andrei Alexandrescu (3/5) Oct 13 2016 The best way is to find 2-3 planned artifacts that have a common theme.
• David Gileadi (3/16) Oct 13 2016 As an ignorant bystander I like core.intrinsics, but if not then perhaps...
• Patrick Schluter (3/26) Oct 13 2016 core.hints
• Stefan Koch (10/12) Oct 13 2016 core.hints ?
• grm (2/16) Oct 14 2016 core.code-gen-rules then?
• Johan Engelen (14/28) Oct 14 2016 I like "hints". It's immediately clear that the functions don't
• Andrei Alexandrescu (2/3) Oct 14 2016 How many other hints are out there? -- Andrei
• Johan Engelen (10/13) Oct 14 2016 Things that come to mind:
• Andrei Alexandrescu (4/16) Oct 14 2016 Any of these present in existing implementations?
• Johan Engelen (12/31) Oct 14 2016 For LLVM, not (yet?) for pointers (there is not builtin for the
• Johan Engelen (6/8) Oct 14 2016 Perhaps not clear, but my point that the functions should _not do
• Andrei Alexandrescu (4/11) Oct 14 2016 I was suggesting we find artifacts that exist and map them in runtime,
• Guillaume Piolat (9/23) Oct 14 2016 - this pointer is aligned to N bytes
• Johan Engelen (6/9) Oct 14 2016 Do you mean these as "just a hint, should not generate invalid
• Guillaume Piolat (4/13) Oct 14 2016 Not a compiler engineer, but it seems to me the compiler should
• David Nadlinger (3/11) Oct 14 2016 For alignment/aliasing restrictions to be really beneficial, you
• Matthias Bentrup (5/17) Oct 15 2016 You could turn "hints" that can possibly create invalid code
• Uplink_Coder (5/9) Oct 15 2016 I cannot think of any hints the would produce incorrect code.
• Patrick Schluter (5/33) Oct 13 2016 but core.intrinsics would have the advantage that it can be used
• Johan Engelen (5/8) Oct 14 2016 And it has the disadvantage that _only_ compiler intrinsics can
• Andrei Alexandrescu (6/9) Oct 14 2016 Walter mentioned there are intrinsics in druntime already, and they're
• Jacob Carlborg (5/7) Oct 13 2016 I don't see a reason why it would need to be short and simple. Less than...

Stefan Koch <uplink.coder googlemail.com> writes:

Hi,

while working on a faster auto-decoding it became oblivous that 
branch-prediction primitives such as the llvm_expect or 
builtin_expect are quite useful and should be avilable in a 
cross-platform compatible way.

I propose to add a new module to to druntime called 
core.intrinsics that would have  functions like
bool likely (bool expr);
bool unlikely (bool expr);
and maybe
void prefetch(void* mem)

Please share your thoughts and tell me what other intrincic 
functions could/should be added.

Johan Engelen <j j.nl> writes:

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

Stefan Koch <uplink.coder googlemail.com> writes:

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 ?

also do you happen to know where llvm_expect is implemented in 
ldc ?
I cannot seem to find it.

Johan Engelen <j j.nl> writes:

On Thursday, 13 October 2016 at 19:52:57 UTC, Stefan Koch wrote:
 
 also do you happen to know where llvm_expect is implemented in 
 ldc ? I cannot seem to find it.

It's at the bottom of druntime/src/ldc/intrinsics.di  (note the 
extension).

Stefan Koch <uplink.coder googlemail.com> writes:

On Thursday, 13 October 2016 at 21:52:22 UTC, Johan Engelen wrote:
 On Thursday, 13 October 2016 at 19:52:57 UTC, Stefan Koch wrote:
 
 also do you happen to know where llvm_expect is implemented in 
 ldc ? I cannot seem to find it.

 It's at the bottom of druntime/src/ldc/intrinsics.di  (note the 
 extension).

I saw that one, but I cannot find the place where ldc checks for 
this template being instantiated.
And then applies the intrinsic.
Which is what I need to see in order to define a sensible way in 
dmd to use those intrinsics.

Johan Engelen <j j.nl> writes:

On Thursday, 13 October 2016 at 19:52:57 UTC, Stefan Koch wrote:
 What name would you suggest then ?

Yeah, that's the problem isn't it... :(

Something with "optimize"?

(I'm thinking the module would combine functions with no 
observable effects, and for which the default implementation does 
nothing.)

Dominikus Dittes Scherkl <Dominikus.Scherkl continental-corporation.com> writes:

On Thursday, 13 October 2016 at 19:52:57 UTC, 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 ?

how about "fuzzylogic"?

Stefan Koch <uplink.coder googlemail.com> writes:

On Thursday, 13 October 2016 at 22:44:13 UTC, Dominikus Dittes 
Scherkl wrote:
 On Thursday, 13 October 2016 at 19:52:57 UTC, 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 ?

 how about "fuzzylogic"?

It has nothing todo with fuzzy logic.
AFAIK fuzzy-logic deals with optimizing boolean logic in order to 
by represented by smaller transistor networks.

core.optimize suggests that there is some functionality that 
optimises things for you which is not the case.

The only thing this should provide are compiler-specific 
low-level tools to affect code-gen.
in as protable a manner as possible.

I am especially intrested in being able to provide hints for 
code-layout.
That does not only affect basic block-placement but also the 
which functions will be placed next to each other if possble.

If anyone has good suggestions as to how such facilites may be 
named I am all ears.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 10/13/2016 06:55 PM, Stefan Koch wrote:
 If anyone has good suggestions as to how such facilites may be named I
 am all ears.

The best way is to find 2-3 planned artifacts that have a common theme. 
Then a name comes up naturally. -- Andrei

David Gileadi <gileadis NSPMgmail.com> writes:

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?

Patrick Schluter <Patrick.Schluter bbox.fr> writes:

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

Stefan Koch <uplink.coder googlemail.com> writes:

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.

grm <gerhard.mueller gmsoft.at> writes:

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?

Johan Engelen <j j.nl> writes:

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.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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

How many other hints are out there? -- Andrei

Johan Engelen <j j.nl> writes:

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)

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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

Johan Engelen <j j.nl> writes:

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.

Johan Engelen <j j.nl> writes:

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.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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

Guillaume Piolat <first.last gmail.com> writes:

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.

Johan Engelen <j j.nl> writes:

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)

Guillaume Piolat <first.last gmail.com> writes:

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.

David Nadlinger <code klickverbot.at> writes:

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

Matthias Bentrup <matthias.bentrup googlemail.com> writes:

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.

Uplink_Coder <uplink.coder googlemail.com> writes:

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.

Patrick Schluter <Patrick.Schluter bbox.fr> writes:

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

Johan Engelen <j j.nl> writes:

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".

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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

Jacob Carlborg <doob me.com> writes:

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