On Thu, Sep 05, 2019 at 09:50:04PM +0000, Stefanos Baziotis via Digitalmars-d wrote: [...]
> - For the first 2, let me thank again Manu and Johan helped who me
>   realize them! Note also that we don't currently know of a way of
>   informing LLVM or GCC about the semantics and thus get this
>   optimization. The closest thing we have is LLVM  recognizing that a
>   function does what e.g. memcpy() does by name. Which is a bad
>   assumption to build upon.

That's pretty scary that LLVM does that. It shakes my confidence in LLVM a little. OTOH, the identifier "memcpy" is pretty unique and practically universally understood to mean C's implementation of it, so it's a reasonably safe assumption. Of course, if you ever wish to override memcpy() with something that does something *other* than memcpy, you could potentially have a vector for Thompson-style backdoors (function does one thing when called, does something else when optimizer picks it up).


[...]
> > This is really the wrong way to go about things IMO; we should rather be fixing DMD's optimizer instead. But once that's done there's even less reason to implement mem* ourselves.
> 
> IMHO, I don't think that fixing the DMD optimizer is a good way to go. Rather, as I said above, aim for generic D implementation, _without_ SIMD, based purely on algorithms. This can be useful for systems that don't have libc and since the DMD optimizer does not use intrinsics as LLVM / GCC, the aforementioned problems, are not problems. Essentially, it's a win-win situation.
[...]

But that seems to me to be quite backwards.  If DMD were to target systems that don't have libc, which AFAIK it currently doesn't, we'd already have to do porting work in the form of how codegen is done. Then whatever implementation of memcpy & co you end up with, will simply become a part of this codegen implementation.  It could be instructions directly produced by the backend, it could be calling a druntime function version'd by that specific platform, etc..  But it'd be a platform-specific, dmd-specific thing, not something generic that applies across all platforms that D might target, and not something that, e.g., GDC or LDC would use.

My point is that something like this seems to be more appropriate as part of the support infrastructure for targeting libc-less platforms, rather than a generic library function that can be used by everyone. So any such implementation would be nested inside a version(platform_XYZ) block, ostensibly something like:

	version(noLibC)
	{
		void _d_memcpy(...) { ... }
	}

where the compiler targeting any platform with no libc would define version=noLibC, and emit references to _d_memcpy as part of the codegen for copying memory.  It just wouldn't be something you could use in general from any platform.


T

-- 
People tell me I'm stubborn, but I refuse to accept it!

On Thursday, 5 September 2019 at 22:56:30 UTC, H. S. Teoh wrote:
>
> That's pretty scary that LLVM does that. It shakes my confidence in LLVM a little. OTOH, the identifier "memcpy" is pretty unique and practically universally understood to mean C's implementation of it, so it's a reasonably safe assumption. Of course, if you ever wish to override memcpy() with something that does something *other* than memcpy, you could potentially have a vector for Thompson-style backdoors (function does one thing when called, does something else when optimizer picks it up).
>

I don't like it either. Although, I _think_ that you can specifically
set this off. Or that it is done by specific flags. I'd have to check.

>
> But that seems to me to be quite backwards.  If DMD were to target systems that don't have libc, which AFAIK it currently doesn't, we'd already have to do porting work in the form of how codegen is done. Then whatever implementation of memcpy & co you end up with, will simply become a part of this codegen implementation.  It could be instructions directly produced by the backend, it could be calling a druntime function version'd by that specific platform, etc..  But it'd be a platform-specific, dmd-specific thing, not something generic that applies across all platforms that D might target, and not something that, e.g., GDC or LDC would use.
>

I don't know if I understood this correctly.
For memcpy() et al to become part of the compiler codegen, they have
to be recognized as intrinsics. Like LLVM does. Is this what you refer to ?
Because that's another (interesting) discussion.

I was talking in the assymption that they're handled as just functions (as now),
and things like a[] = b[] just call memcpy().
In that case, it doesn't pay to write arch-specific (meaning, the function
implementor, not the compiler) implementation. Because that can't be leveraged
across architectures (or you have to write a specific one for each which is
not a good goal because of maintenance).

Even if there was an LLVM-like thing where you can e.g. call vector extension
intrinsics, but these are lowered to whatever arch-specific thing. Even if the
arch does not have the concept of vectorization. Even then, it would be better
to focus on the algorithmic part, as the translation of the compiler would
be relatively basic.

I hope the above made _some_ sense. I feel I didn't articulate my thoughts
perfectly.

- Stefanos

On Thursday, 5 September 2019 at 22:56:30 UTC, H. S. Teoh wrote:
> On Thu, Sep 05, 2019 at 09:50:04PM +0000, Stefanos Baziotis via Digitalmars-d wrote: [...]
>> - For the first 2, let me thank again Manu and Johan helped who me
>>   realize them! Note also that we don't currently know of a way of
>>   informing LLVM or GCC about the semantics and thus get this
>>   optimization. The closest thing we have is LLVM  recognizing that a
>>   function does what e.g. memcpy() does by name. Which is a bad
>>   assumption to build upon.
>
> That's pretty scary that LLVM does that. It shakes my confidence in LLVM a little. OTOH, the identifier "memcpy" is pretty unique and practically universally understood to mean C's implementation of it, so it's a reasonably safe assumption.

FYI, GCC does the same.

(the opposite too: converting a copying pattern into memcpy is an optimization performed by LLVM, GCC, and MSVC)

-Johan

On Thursday, 5 September 2019 at 21:33:37 UTC, Stefanos Baziotis wrote:

> For the second, I guess you mean "if you were shown".

No, I *had* been showed.

Regardless this is major disappointment. Good work has gone to waste. I can not believe it was accepted in the first place, if it were turn out to be pointless.
This speaks very poorly of the d language foundation, IMO. You better close those PR request, as it quite clear that they are never going to be accepted.

- Alex

On Friday, 6 September 2019 at 01:50:59 UTC, 12345swordy wrote:
> On Thursday, 5 September 2019 at 21:33:37 UTC, Stefanos Baziotis wrote:
>
> No, I *had* been showed.

Ok, I'm not aware.

>
> Regardless this is major disappointment. Good work has gone to waste. I can not believe it was accepted in the first place, if it were turn out to be pointless.
> This speaks very poorly of the d language foundation, IMO. You better close those PR request, as it quite clear that they are never going to be accepted.
>
> - Alex

It will be closed yes. I hope that it will not go completely wasted.
When I have time, I will gather the useful code in one repo of D, C and
assembly versions. I think there are some important things to take.

- Stefanos