Re: Target attribute hooks questions

[Kyrill Tkachov <kyrylo dot tkachov at arm dot com>]

Hi Christian,

On 05/05/15 15:25, Christian Bruel wrote:
> Hi Kyrill,
>
> you are right it's not easy to get its way among all those macros, my
> main source of inspiration for ARM was the x86 implementation.

Yeah, I've been looking at that and rs6000 for some perspective.

> You can have a look at the ARM implementation to start with (on
> gcc-patches, under review). That would be best not to diverge too much
> aarch64 might have a few code to share with the arm be. FYI I'm planning
> to add the fpu/neon attribute extensions
>
> A few quick answer bellow, ask if you need more.
>
> Cheers
>
> Christian
>
> On 05/05/2015 03:38 PM, Kyrill Tkachov wrote:
> > Hi all,
> >
> > I'm looking at implementing target attributes for aarch64 and I have some questions about the hooks involved.
> > I haven't looked at this part of the compiler before, so forgive me if some of them seem obvious. I couldn't
> > figure it out from the documentation (https://gcc.gnu.org/onlinedocs/gccint/Target-Attributes.html#Target-Attributes)
> >
> > * Seems to me that TARGET_OPTION_VALID_ATTRIBUTE_P is the most important one that parses
> > the string inside the __attribute__ ((target ("..."))) and sets the target-specific
> > flags appropriately. Is that correct?
> Yes, it parses the string that goes into DECL_FUNCTION_SPECIFIC_TARGET
> (fndecl) and then builds the struct gcc_options that will be switched
> between functions. Note that this gone must go again to the
> option_override machinery since global options can be affected by the
> target options.

Right, so I'll need to call the option_override hook manually...

> > * What is TARGET_ATTRIBUTE_TABLE used for? It's supposed to map attributes to handlers?
> > Isn't that what TARGET_OPTION_VALID_ATTRIBUTE_P is for?
> I think it's different.  the TARGET_ATTRIBUTE_TABLE specifies specific
> attributes (e.g naked, interrupt, ...) while the target attribute allows
> to pass target flags (e.g: -marm, -mfpu=neon, ...)

Ok, I see from the rs6000 backend that it's something different, I'll leave it alone for now.

> > * What is the use of TARGET_OPTION_SAVE and TARGET_OPTION_RESTORE? Is that used during
> >    something like LTO when different object files and functions are compiled with different
> > flags? Are these functions just supposed to 'backup' various tuning and ISA decisions?
> This is to save custom function information that are not restored by
> TARGET_SET_CURRENT_FUNCTION. I didn't need it for arm/thumb.

I'm looking at these in the context of LTO. From what I understand, LTO uses target attributes
to tag each function with target-specific flags so that it can keep track of the flags when
linking object files compiled with different target flags (e.g. different mcpu options).
Which hooks are used in this process?

> > * Is TARGET_COMP_TYPE_ATTRIBUTES the one that's supposed to handle incompatible attributes
> > being specified? (for example incompatible endianness or architecture levels)?
> like TARGET_ATTRIBUTE_TABLE, it's different and doesn't pertain to
> attribute target

Thanks for the help!
Kyrill

> Cheers
>
> Christian
>
> > Thanks for any insight,
> > Kyrill