* Frontend access to target-related options @ 2020-01-01 9:32 The Other 2020-01-02 16:54 ` Nathan Sidwell 0 siblings, 1 reply; 6+ messages in thread From: The Other @ 2020-01-01 9:32 UTC (permalink / raw) To: gcc 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. Thanks, Theo ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Frontend access to target-related options 2020-01-01 9:32 Frontend access to target-related options The Other @ 2020-01-02 16:54 ` Nathan Sidwell 2020-01-07 13:16 ` Richard Biener 0 siblings, 1 reply; 6+ messages in thread From: Nathan Sidwell @ 2020-01-02 16:54 UTC (permalink / raw) To: The Other, gcc 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? nathan -- Nathan Sidwell ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Frontend access to target-related options 2020-01-02 16:54 ` Nathan Sidwell @ 2020-01-07 13:16 ` Richard Biener 2020-01-08 9:12 ` The Other 0 siblings, 1 reply; 6+ messages in thread From: Richard Biener @ 2020-01-07 13:16 UTC (permalink / raw) To: Nathan Sidwell; +Cc: The Other, GCC Development On Thu, Jan 2, 2020 at 5:54 PM Nathan Sidwell <nathan@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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Frontend access to target-related options 2020-01-07 13:16 ` Richard Biener @ 2020-01-08 9:12 ` The Other 2020-01-08 10:04 ` Andrew Pinski 0 siblings, 1 reply; 6+ messages in thread From: The Other @ 2020-01-08 9:12 UTC (permalink / raw) To: Richard Biener; +Cc: Nathan Sidwell, GCC Development 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). 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.guenther@gmail.com> wrote: > On Thu, Jan 2, 2020 at 5:54 PM Nathan Sidwell <nathan@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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Frontend access to target-related options 2020-01-08 9:12 ` The Other @ 2020-01-08 10:04 ` Andrew Pinski 2020-01-08 13:52 ` The Other 0 siblings, 1 reply; 6+ messages in thread From: Andrew Pinski @ 2020-01-08 10:04 UTC (permalink / raw) To: The Other; +Cc: Richard Biener, Nathan Sidwell, GCC Development On Wed, Jan 8, 2020 at 1:16 AM The Other <simplytheother@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.guenther@gmail.com> > wrote: > > > On Thu, Jan 2, 2020 at 5:54 PM Nathan Sidwell <nathan@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 > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Frontend access to target-related options 2020-01-08 10:04 ` Andrew Pinski @ 2020-01-08 13:52 ` The Other 0 siblings, 0 replies; 6+ messages in thread From: The Other @ 2020-01-08 13:52 UTC (permalink / raw) To: Andrew Pinski; +Cc: Richard Biener, Nathan Sidwell, GCC Development 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 <pinskia@gmail.com> wrote: > On Wed, Jan 8, 2020 at 1:16 AM The Other <simplytheother@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.guenther@gmail.com> > > wrote: > > > > > On Thu, Jan 2, 2020 at 5:54 PM Nathan Sidwell <nathan@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 > > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-01-08 13:52 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-01-01 9:32 Frontend access to target-related options The Other 2020-01-02 16:54 ` Nathan Sidwell 2020-01-07 13:16 ` Richard Biener 2020-01-08 9:12 ` The Other 2020-01-08 10:04 ` Andrew Pinski 2020-01-08 13:52 ` The Other
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).