I'm just working from the somewhat incomplete Rust spec at this point - intrinsics and other complicated target-dependent stuff don't seem to be part of it. Rust seems to provide vector intrinsics through libraries with inline assembly.
For the frontend, I just need a list of strings describing the "features available", which is used for conditional compilation. Like how you'd use preprocessor macros to do #ifdef __SSE__. Basically, what I need doesn't really have anything to do with vector support - I just need to know about the presence or lack of presence of features. I was intending to do a rust_target_objs if there were no other alternatives, as I would have to do one for every supported target to my knowledge, which seems like a waste of effort if I could leverage a pre-existing target hook. By the way, is the x_target_objs file the only required one for a target hook like that? Or are other files with other code required? Thanks, Theo On Wed, Jan 8, 2020 at 6:04 PM Andrew Pinski <pins...@gmail.com> wrote: > 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 > > > >
