Frontend access to target-related options

The Other simplytheother@gmail.com
Wed Jan 8 13:52:00 GMT 2020


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



More information about the Gcc mailing list