Hi Jerno,

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.

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.

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

I've added a gen_gccbuiltins.cpp to my fork of LDC
at https://github.com/jerro/ldc/commit/3500f3489aaf9f95e9b5c469c438efc68...
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.

Nice, thanks a lot for your work!

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

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

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