[cfe-dev] Diagnosing Incompatible Attributes Between a Calling Function and the Callee Function
Eli Friedman via cfe-dev
cfe-dev at lists.llvm.org
Thu Jan 10 12:06:55 PST 2019
On 1/10/2019 10:44 AM, Zola Bridges via cfe-dev wrote:
>
> Hi everyone,
>
> *
> *
>
> I'm working on adding function level Clang attributes for the
> Speculative Load Hardening (SLH) feature, so devs who know what they
> are doing can enable or disable SLH function by function. There are
> two attributes 'no_speculative_load_hardening' and
> 'speculative_load_hardening.'
>
> *
> *
>
> As a part of this, I want to diagnose a special case where a function
> marked
>
> 'no_speculative_load_hardening' will still have
> 'speculative_load_hardening' enabled.
>
> *
> *
>
> Whenever a function marked 'speculative_load_hardening' is inlined
> into another function, then that function that it was inlined into
> will have SLH enabled no matter what. [If you want more info on the
> rationale for this, check out the patch comments here:
> https://reviews.llvm.org/D54909?id=175599#inline-487979]
>
> I want to diagnose cases similar to this example:
>
> *
> *
>
> __attribute__((speculative_load_hardening)) inline int foo(int i) {
>
The "inline" keyword here is basically irrelevant; we aren't required to
inline functions marked inline, and we can inline functions which are
not marked "inline". (The "inline" keyword has other effects related to
linkage, but they don't have any effect on the arguments here.)
In general, it's impossible to catch all cases of a
no_speculative_load_hardening calling a speculative_load_hardening
function in the frontend: a no_speculative_load_hardening might call a
speculative_load_hardening indirectly, or the callee might be in a
different translation unit. (The optimizer may or may not discover the
call later, depending on the exact construct in question and the
optimization flags.)
Given that, I'm not sure your proposed diagnostic makes sense; even if
you could diagnose constructs like your example, you'd be missing all
the important cases.
Also, if the general rule is "the optimizer may choose to perform SLH on
a function even if it's marked no_speculative_load_hardening", you
should probably avoid specifically mentioning inlining in the
documentation, since it's misleading. (Other optimizations might be
affected by this rule, like function merging or outlining.)
> *
> *
>
> 2. Add the diagnosis to CheckFunctionCall or checkCall in SemaChecking.cpp
>
> *
> *
>
> Why doesn't this work?
>
> The context about the caller of the callee isn't available. I need to
> know whether the caller has the 'no_speculative_load_hardening' attribute.
>
The context should be available; you can call
Sema::getEnclosingFunction(), or something like that.
-Eli
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190110/c4e15cc7/attachment.html>
More information about the cfe-dev
mailing list