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. 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. > > * 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 Cheers Christian > > Thanks for any insight, > Kyrill >