search for: __builtin_unpredictable

I’m struggling to find cases where __builtin_unpredictable() works at all. Even if we ignore cmp/br into switch conversion, it still doesn’t work: int test_cmov(int left, int right, int *alt) { return __builtin_unpredictable(left < right) ? *alt : 999; } Should generate: test_cmov: movl $999, %eax cmpl %esi, %edi cmovll (%rdx), %eax retq But cu...

Hi Chandler, I feel like this conversation has come full circle. So to ask again: how does one force CMOV to be emitted? You suggested “__builtin_unpredictable()” but that gets lost in various optimization passes. Given other architectures have CMOV like instructions, and given the usefulness of the instruction for performance tuning, it seems like a direct intrinsic would be best. What am I missing? Dave > On Sep 14, 2019, at 8:35 AM, Chandler Carru...

...> > 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 <https://godbolt.org/z/S46I_q> Dave -------------- next part -------------- An HTML attachment was scrubbed.....

On 9/12/19 5:06 AM, David Zarzycki via llvm-dev wrote: I think adding a builtin to force CMOV or similar instructions on other architectures is long overdue. It’s generally useful, even if one isn’t mitigating speculative execution. I believe that you can currently get this effect using __builtin_unpredictable in Clang. __builtin_unpredictable wasn't added for this purpose, and it's a hint not a forced behavior, but I believe that it causes the backend to prefer cmov to branches during lowering. -Hal On Sep 12, 2019, at 12:30 PM, Daan Sprenkels via llvm-dev <llvm-dev at lists.llvm.org<m...

...19 5:06 AM, David Zarzycki via llvm-dev wrote: >> I think adding a builtin to force CMOV or similar instructions on other architectures is long overdue. It’s generally useful, even if one isn’t mitigating speculative execution. > > I believe that you can currently get this effect using __builtin_unpredictable in Clang. __builtin_unpredictable wasn't added for this purpose, and it's a hint not a forced behavior, but I believe that it causes the backend to prefer cmov to branches during lowering. > > I want to strongly advise against relying on this for anything to do with cryptography. The...

Hello all, Many of us are dealing with data that should remain secret on a daily basis. In my case, that's key material in cryptographic implementations. To protect against side-channel attacks. We write our code in such a way that the execution of the program is not dependent on the key and other secret values. However compiler optimizations often makes this very hard for us, and often our

...right.com> Cc: llvm-dev <llvm-dev at lists.llvm.org>; cfe-dev <cfe-dev at lists.llvm.org>; David Li <davidxl at google.com>; Nick Lewycky <nicholas at mxc.ca> Subject: Re: [cfe-dev] [llvm-dev] [RFC] remove the llvm.expect intrinsic Your patch does make the handling of __builtin_unpredictable and __builtin_expect 'unified' in some way. However given the point brought up by Reid, and the rationale by Richard, as well as consideration of the easiness for enhancement in the future, I think keep the current mechanism is a better approach. The test cases from Richard are bro...

I, of course, thought the ~100 lines added by D19299 was a reasonable trade for the ~800 lines removed in D19300. David Li (and anyone else following along), do you still like those patches after hearing this objection or should I abandon? On Fri, Apr 22, 2016 at 11:55 AM, Reid Kleckner <rnk at google.com> wrote: > Sorry, I didn't realize that was the clang side. > > I think