Frontend access to target-related options

Frontend access to target-related options

[The Other]

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

Re: Frontend access to target-related options

[Nathan Sidwell]

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

Re: Frontend access to target-related options

[Richard Biener]

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

Re: Frontend access to target-related options

[The Other]

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
>

Re: Frontend access to target-related options

[Andrew Pinski]

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
> >

Re: Frontend access to target-related options

[The Other]

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
> > >
>