[cfe-dev] Folding constexpr function calls with constant arguments in non constant expression contexts

[David Blaikie via cfe-dev]

On Tue, Mar 7, 2017 at 3:10 AM Roger Ferrer Ibanez <
Roger.FerrerIbanez at arm.com> wrote:

> Thanks David for your answer, would it make sense to do this at CodeGen
> under –O?
>

I doubt it - the Clang code isn't really designed to be an efficient
optimizer. If this is a missed optimization, it'd likely be best to look at
why the LLVM optimization pipeline is missing the opportunity.


>
>
> Something like, in CodegenFunction::EmitCallExpr check that we’re calling
> a constexpr function, then attempt to evaluate it, and then forward down a
> llvm::Constant* until CodeGenFunction::EmitCall (the one in CGCall.cpp).
> Then there if given a non-null llvm::Constant*, use that to create and
> return the RValue. This seems unnecessarily complicated but should emit
> everything else required at that point except the function call itself.
>
>
>
> Kind regards,
>
> Roger
>
>
>
> *From:* David Blaikie [mailto:dblaikie at gmail.com]
> *Sent:* 22 February 2017 16:16
> *To:* Roger Ferrer Ibanez; Clang Dev; Richard Smith
> *Subject:* Re: [cfe-dev] Folding constexpr function calls with constant
> arguments in non constant expression contexts
>
>
>
> I'm going to guess it's mostly (3). Checking and trying to constant
> evaluate every subexpression would be expensive - the systems to do so in
> Clang have to do a lot of work to properly report diagnostics, to act on
> the full AST form, etc. It's easier to leave it to the LLVM optimization
> passes to do the work, when possible.
>
> On Wed, Feb 22, 2017 at 1:58 AM Roger Ferrer Ibanez via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> Hi all,
>
> maybe this is just a silly question. But I wondered why clang is not
> attempting to fold calls to constexpr functions in non-constant expression
> contexts.
>
> Example:  https://godbolt.org/g/KBaMjp just compare "one" vs "two" in the
> IR
>
> I understand that clang does not have to do this and I'm not saying it
> should.
>
> But I'd like to know what is the rationale here.
> - Is it a C++ Standard issue?, i.e. doing that would trigger some
> side-effects that would be non-compliant.
> - Is it a "separation of concerns" issue?, i.e. let LLVM optimize these
> cases and improve if it can't.
> - Is it a speed issue?, i.e. even if the original AST is preserved for
> fidelity, computing an associated constant value to it takes time which is
> precious for some clients.
>
> Or maybe it is something else that didn't occur to me.
>
> Thank you,
> Roger
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://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/20170307/229d318a/attachment.html>