[cfe-dev] Emit target specific defines based on CodeGenOptions

[Tamas Petz via cfe-dev]

Hi Eli,

Thank you, I think I'll move related code from CodeGenOptions to LangOptions then.

- Tamas

________________________________
From: Eli Friedman <efriedma at quicinc.com>
Sent: Thursday, March 26, 2020 5:12 PM
To: Tamas Petz <Tamas.Petz at arm.com>; cfe-dev at lists.llvm.org <cfe-dev at lists.llvm.org>
Subject: RE: [cfe-dev] Emit target specific defines based on CodeGenOptions

If an option has an effect on preprocessing/semantic analysis, it shouldn't be in CodeGenOptions; it should be in LangOptions.

-Eli

> -----Original Message-----
> From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of Tamas Petz via
> cfe-dev
> Sent: Thursday, March 26, 2020 1:36 AM
> To: cfe-dev at lists.llvm.org
> Subject: [EXT] [cfe-dev] Emit target specific defines based on CodeGenOptions
>
> Dear List,
>
> I am looking into adding some new Arm-specific feature test macros defined by
> the latest release of ACLE:
> https://developer.arm.com/docs/101028/0010/feature-test-macros
>
> Namely these are __ARM_FEATURE_BTI_DEFAULT
> and __ARM_FEATURE_PAC_DEFAULT.
>
> However, CodeGenOptions is not accessible from TargetInfo, as far as I can tell,
> and there is no use-case for emitting such a define as of today.
>
> I am asking for some advice how to implement it correctly.
>
> I think there are three possible solutions:
>
> 1. Refactor getTargetDefines() to have CodeGenOptions as argument, pass
> CodeGenOptions through preprocessor.
>
> 2. Use adjustTargetOptions(), remove const qualifier, store state in
> AArch64TargetInfo, use stored state to generate macros.
>
> 3. Add new virtual function to TargetInfo (getTargetDefinesCGO()?), pass
> CodeGenOptions through preprocessor, invoke getTargetDefinesCGO() right
> after getTargetDefines().
>
> I would prefer option 1 but it is a massive diff.
>
> What do you think? Is there a better way to achieve this?
>
> Looking forward to you comments.
>
> Best regards,
> Tamas Petz
>
> u.i.: should be there a disclaimer in this mail, please ignore it.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200331/35a54a6b/attachment-0001.html>