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
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
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
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
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
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
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
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
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? --
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,
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
On 10/14/2016 05:24 AM, Johan Engelen wrote:
I like "hints".
How many other hints are out there? -- Andrei
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
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_
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
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
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
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
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
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 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
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 by
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
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.
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
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
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).
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
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" /
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
30 matches
Mail list logo
