[llvm-dev] Side-channel resistant values

[Craig Topper via llvm-dev]

I don't think the X86 cmov converter pass knows about unpredictable? Do we
even preserve that metadata into Machine IR?

There's also this frontend bug with the builtin getting translated to IR
https://bugs.llvm.org/show_bug.cgi?id=40031

~Craig


On Fri, Sep 13, 2019 at 2:18 PM Sanjay Patel via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I'm not sure if this is the entire problem, but SimplifyCFG loses the
> 'unpredictable' metadata when it converts a set of cmp/br into a switch:
> https://godbolt.org/z/neLzN3
>
> Filed here:
> https://bugs.llvm.org/show_bug.cgi?id=43313
>
> On Fri, Sep 13, 2019 at 4:02 AM David Zarzycki via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>>
>> On Sep 13, 2019, at 10:45 AM, Chandler Carruth <chandlerc at gmail.com>
>> wrote:
>>
>> On Fri, Sep 13, 2019 at 1:33 AM David Zarzycki via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hi Chandler,
>>>
>>> The data-invariant feature sounds great but what about the general case?
>>> When performance tuning code, people sometimes need the ability to reliably
>>> generate CMOV, and right now the best advice is either “use inline
>>> assembly” or “keep refactoring until CMOV is emited” (and hope that future
>>> compilers continue to generate CMOV).
>>>
>>> Given that a patch already exists to reliably generate CMOV, are there
>>> any good arguments against adding the feature?
>>>
>>
>> For *performance* tuning, the builtin that Hal mentioned is IMO the
>> correct design.
>>
>> Is there some reason why it doesn't work?
>>
>>
>> I wasn’t aware of __builtin_unpredictable() until now and I haven’t
>> debugged why it doesn’t work, but here are a couple examples, one using the
>> ternary operator and one using a switch statement:
>>
>> https://godbolt.org/z/S46I_q
>>
>> Dave
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190913/78042f04/attachment.html>