Target attribute hooks questions

Christian Bruel
Tue May 5 14:25:00 GMT 2015

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.

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.



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 (
> * 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.

> * 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, ...)

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

> * 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 any insight,
> Kyrill

More information about the Gcc mailing list