[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

On 2020. 03. 26. 17:13, "Eli Friedman" <efriedma at quicinc.com> wrote:

    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