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
> 

Reply via email to