LDC __builtin_ia32_* declarations

[David Nadlinger]

Hi Jerno,

On Wed, Oct 10, 2012 at 7:41 PM, j j <jerro....@gmail.com> wrote:
> Hi, I'd like to talk to you about declarations for gcc builtin x86
> intrinsics in LDC. I think it would be useful if LDC provided a module
> containing the declarations for those intrinsics, like for example
> this one:
>
> pragma(intrinsic, "llvm.x86.sse.min.ps")
> float4 __builtin_ia32_minps (float4, float4);

It certainly would be an useful addition, at the very least for
porting C/C++ SIMD code, and we should be able to get all the
necessary information out of LLVM/Clang tablegen files, as they are
installed into include/ anyway.

> What I don't know is where these declarations should go - should they
> be publicly imported into llvm.intrinsics, or should there be in a
> separate module, for example llvm.gccbuiltins?

I think I'd prefer creating a new ldc.gccbuiltins module just for the
sake of keeping everything nice and tidy, but I don't really have a
strong opinion on it.

> I'm currently using the script at https://gist.github.com/3851893 to
> generate the gcc builtin declarations from IntrinsicsX86.td. It is
> written in D, so I guess I would have to rewrite it in something else
> (probably C++) if we wanted to use it at build time.

One option would be to just build your tool after druntime and Phobos
have been built. However, in theory someone could want to build LDC
for a target which is not the host target, so yes, it might be a wise
idea not to introduce a dependency on D in our build process.

However, there might be a more elegant way to do it anyway: According
to the folks in #llvm, it should not be hard to write a custom
TableGen-based tool to directly gather the information we need, using
llvm/TableGen/*.h and libLLVMTableGen.a. For reference, see
utils/TableGen/IntrinsicsEmitter.cpp (a piece of code emitting a list
of all GCC builtins was removed in r153432).

Anyway, thanks a lot for looking into this – I'd very much like to see
an addition like this.

David

[jerro]

I've added a gen_gccbuiltins.cpp to my fork of LDC at https://github.com/jerro/ldc/commit/3500f3489aaf9f95e9b5c469c438efc6845ec1ee and modified the cmake scripts so that gccbuiltns.di is generated at built time and installed in $prefix/include/d/ldc/ . I have added a target for gen_gccbuiltins to the toplevel CMakeLists.txt. The resulting executable gen_builtins is later used to generate gccbuiltins.di as a dependency of druntime. I didn't know where to put gen_gccbuiltins.cpp, so I have just put it in the toplevel directory (although it should probably go somewhere else). 

 

Do you have an opinion on where gen_gccbuiltins.cpp should go? Do you think this is the right way to add gccbuiltins.di ? If so, I will be making a pull request. 

[David Nadlinger]

On Fri, Oct 12, 2012 at 1:09 AM, jerro <jerro....@gmail.com> wrote:
> I've added a gen_gccbuiltins.cpp to my fork of LDC at
> https://github.com/jerro/ldc/commit/3500f3489aaf9f95e9b5c469c438efc6845ec1ee
> and modified the cmake scripts so that gccbuiltns.di is generated at built
> time and installed in $prefix/include/d/ldc/ .

Nice, thanks a lot for your work!

> Do you have an opinion on where gen_gccbuiltins.cpp should go? Do you think
> this is the right way to add gccbuiltins.di ? If so, I will be making a pull
> request.

Yes, top-level is not optimal, it's way too crowded as it is. We
should really have a src directory, but I don't want to break all the
history and patches right now (but I'll probably move all the config
files to a separate directory). What about just runtime/, or maybe
better a new util/ directory?

But yes, I think this is the right way to handle GCC intrinsics, so it
would be great if you could prepare a pull request.

One little note: It seems like you only generate the x86 intrinsics. I
have not looked at the matter in detail – would it make sense to
include the architecture in the module name so we can have multiple
archs side by side (cross-compiling, ...)? The build system should
probably also handle the case where host/target are not x86, but this
can wait until a later point in time.

David

[jerro]

Yes, top-level is not optimal, it's way too crowded as it is. We
should really have a src directory, but I don't want to break all the
history and patches right now (but I'll probably move all the config
files to a separate directory). What about just runtime/, or maybe
better a new util/ directory?

I've created a util directory and put it there.  

 

But yes, I think this is the right way to handle GCC intrinsics, so it
would be great if you could prepare a pull request.

One little note: It seems like you only generate the x86 intrinsics. I
have not looked at the matter in detail – would it make sense to
include the architecture in the module name so we can have multiple
archs side by side (cross-compiling, ...)? The build system should
probably also handle the case where host/target are not x86, but this
can wait until a later point in time. 

The module's API depends on the architecture, so I think it does make sense to include the architecture in the module name. I've renamed the module to ldc.gccbuiltins_x86. 

gen_gccbuiltins takes arch as a command line parameter  , so gen_gccbuiltins.cpp doesn't need to be changed to support other architectures. This is not as useful for all architectures as it is for X86, though. For arm NEON, for example, LLVM does provide a lot of intrinsics, but not in the form of gcc builtins, so the gcc builtins module doesn't help you much there. 

I'l open a pull request now. 

David