[GSoC] 'Independency of D from the C Standard Library' progress and update thread

[H. S. Teoh]

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!