This is the mail archive of the
mailing list for the GCC project.
Re: Target attribute hooks questions
- From: Kyrill Tkachov <kyrylo dot tkachov at arm dot com>
- To: Christian Bruel <christian dot bruel at st dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 05 May 2015 15:41:22 +0100
- Subject: Re: Target attribute hooks questions
- Authentication-results: sourceware.org; auth=none
- References: <5548C7C3 dot 8080602 at arm dot com> <5548D2D6 dot 9070407 at st dot com>
On 05/05/15 15:25, Christian Bruel wrote:
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.
On 05/05/2015 03:38 PM, Kyrill Tkachov wrote:
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
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
Thanks for the help!
Thanks for any insight,