On Wed, Jan 8, 2020 at 1:16 AM The Other <simplytheot...@gmail.com> wrote: > > I've found the code for the target hooks for both the C-family and D > frontends (or at least their implementation for the i386 platform). The > C-family ones seem like they probably are too tied to the preprocessor to > be usable for other languages (which I assume is the reason that the D > frontend created their own target hooks). I'm not sure if functions like > "cpp_assert" and "cpp_define" are actually directly defined or if they have > a macro indirection layer (like lang hooks have macro indirection layers > with LANG_HOOKS_INIT), but I suspect that they're defined, and so the > one-definition rule of C++ prevents any overloading from any other > frontend. As such, the C-family target hooks appear to be unusable for my > purpose. > > On the other hand, the D frontend target hooks don't appear to provide > enough information relating to the target system to be useful (e.g. they > seem to be missing features like SSE support and whatever).
GCC has a generic vector support so usually other languages don't need to export that. What exact information do you need to provide here? That is what does Rust need for SSE support? Can you just use the generic vector support or are there intrinsics (builtins) support that is needed? Do you need to know about the builtins that the target supplies? and then make intrinsics out of them? Why not a rust_target_objs like there is for c_target_objs/cxx_target_objs in config.gcc. Just like how D added d_target_objs too? And then you have one or two defines which will add the builtins like you need to do it. Thanks, Andrew Pinski > As such, I think it looks like I'd have to add a new target hook. How would > I go about doing this? Is there any documentation on doing so? > > Thanks, > Theo > > On Tue, Jan 7, 2020 at 9:16 PM Richard Biener <richard.guent...@gmail.com> > wrote: > > > On Thu, Jan 2, 2020 at 5:54 PM Nathan Sidwell <nat...@acm.org> wrote: > > > > > > On 1/1/20 4:31 AM, The Other wrote: > > > > Hi, > > > > I'm currently working on a Rust frontend for GCC. Rust has some > > > > language-level conditional compilation features based on the presence > > or > > > > lack of features in the target architecture (e.g. SSE, AVX, a static C > > > > runtime) as well as the target CPU architecture itself, target OS, and > > > > various other target-related information (such as pointer width and > > > > endianness). > > > > > > > > As such, the frontend parser requires this target-related option > > > > information to be available to it. I was wondering if there was an > > > > architecture-neutral way of accessing this data (if it is even stored). > > > > I've looked into options.h but I cannot figure out how to use it in an > > > > architecture-neutral way. > > > > > > Um, AVX and such are arch-specific. It sounds like you need some kind > > > of (new?) langhook that targets can register? > > > > You mean target hook. Depending on the actual piece of info such hook > > might already exist though. > > > > Richard. > > > > > nathan > > > > > > -- > > > Nathan Sidwell > >
