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
