search for: zarzycki

...t;chandlerc at gmail.com> wrote: > >  > The x86 backend is extremely aggressive in turning cmov with memory operands into branches because that is often faster even for poorly predicted branches due to the forced stall in the cmov. > >> On Fri, Sep 13, 2019 at 11:19 PM David Zarzycki <dave at znu.io> wrote: >> 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...

...t 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 Chand...

> 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 <mailto: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...

Dave Zarzycki <zarzycki at apple.com> writes: >>From chats with some llvm/clang developers at Apple, we're also stuck on: > > 3) Somebody doing all of the thankless infrastructure work to ensure > that we don't regress on basic things like the web interface, > post-commit email h...

...> > 2018-05-09 20:33 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com <mailto:david.bolvansky at gmail.com>>: > I did > > https://bugs.llvm.org/show_bug.cgi?id=37368 <https://bugs.llvm.org/show_bug.cgi?id=37368> > > 2018-05-09 20:29 GMT+02:00 David Zarzycki <dave at znu.io <mailto:dave at znu.io>>: > I’d wager that the if-else chain is being converted to a "switch statement” during an optimization pass and the __builtin_expect() hint is lost. Can you file a bug? https://bugs.llvm.org <https://bugs.llvm.org/> > > >&...

...struct B { > const A a{}; > void m(B &&other) { > a = std::move(other.a); > } > }; > > int main() { > B b1, b2; > b2.m(std::move(b1)); > } > > Best wishes, > Vit > > <log.txt> > >> 29 марта 2018 г., в 7:06, David Zarzycki <dave at znu.io <mailto:dave at znu.io>> написал(а): >> >> Can you be more specific? What version of clang are you using to build LLVM? And what exactly is the error that you’re seeing? >> >>> On Mar 28, 2018, at 23:38, vit9696 via llvm-dev <llvm-dev at l...

...g the feature? Dave > On Sep 12, 2019, at 10:21 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Thu, Sep 12, 2019 at 9:18 AM Finkel, Hal J. via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > 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...

Hello, May I ask anyone responsible to either fix or revert r326109 and r326110, which effectively broke LLVM compilation with clang? Str is const now (https://reviews.llvm.org/D43436#C985082NL45 <https://reviews.llvm.org/D43436#C985082NL45>), and later on a move constructor on const is performed (https://reviews.llvm.org/D43436#C985082NL64

On Aug 19, 2011, at 2:57 AM, FlyLanguage wrote: >> On Aug 18, 2011, at 10:57 AM, David Greene wrote: >>> >>> Did the project ever come to a decision about making a transition to >>> git? I'm trying to do some longer-term planning and it would be helpful >>> to know what the roadmap is. > > It's stuck on: > > 1) A misunderstanding

...ong communication and teamwork skills * Experience with library/compiler interactions and platform ABIs * Knowledge of object file formats and semantics * Knowledge of Objective-C specific features is a plus * Knowledge of low-level Apple specific runtime features is a plus Job #13014171 -- Dave Zarzycki (zarzycki at apple.com) Low-Level Runtime Manager Apple Inc.

Thanks, interesting. But a fix needs to be made since branch predictor hints are broken in a valid C++20 code: https://godbolt.org/g/dpSDqd Dňa st 9. 5. 2018, 20:40 David Zarzycki <dave at znu.io> napísal(a): > Hi Dávid, > > Looks like you can defeat the switch conversion by adding a dummy asm(“”): > > #define likely(x) __builtin_expect((x),1) > > // switch like > char * b(int e) { > if (likely(e == 0)) > return "0&...

On 05/02/2012 01:00 PM, Dave Zarzycki wrote: > Shea, > > Feasible? Sure, anything is feasible. A good idea? Not really. The internal lld file format is an _intermediate_ data structure designed to make creating the final executable straightforward and fast. It isn't designed to be an executable format itself. In fact, the...

Hi Jake, About a year ago in commit 5049c3422d26b2b68877307c41b35d7e6aae3235, you attempted to solve a race in llvm-objcopy. What was the race? I ask because unless "last change wins" is the result you want, then the race isn't solved. The problem is that `sys::fs::rename` is just a thin wrapper around POSIX semantics, and replacing an existing file is not an error. Dave

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_...

> On Apr 30, 2018, at 15:05, John McCall via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> On Apr 30, 2018, at 2:58 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: >> On Mon, Apr 30, 2018 at 11:14 AM, John McCall <rjmccall at apple.com> wrote: >>> The LLVM address space design has pushed well beyond the sensible boundaries >>> of

I did https://bugs.llvm.org/show_bug.cgi?id=37368 2018-05-09 20:33 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>: > I did > > https://bugs.llvm.org/show_bug.cgi?id=37368 > > 2018-05-09 20:29 GMT+02:00 David Zarzycki <dave at znu.io>: > >> I’d wager that the if-else chain is being converted to a "switch >> statement” during an optimization pass and the __builtin_expect() hint is >> lost. Can you file a bug? https://bugs.llvm.org >> >> >> On May 9, 2018, at 1:57...

On 3 May 2018, at 22:09, David Zarzycki via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > In an effort to help LLVM-style projects save memory, I’ve been toying with some macros that provide an alternative to C++ vtables that use LLVM-style RTTI design patterns instead. Is this something that LLVM or sub...

> On Apr 30, 2018, at 2:58 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > On Mon, Apr 30, 2018 at 11:14 AM, John McCall <rjmccall at apple.com> wrote: >> The LLVM address space design has pushed well beyond the sensible boundaries >> of less-is-more and really needs some concerted effort to actually define the expected >> properties of different

Hello, In an effort to help LLVM-style projects save memory, I’ve been toying with some macros that provide an alternative to C++ vtables that use LLVM-style RTTI design patterns instead. Is this something that LLVM or sub-projects think is worth pursuing? Or are the macros below too ugly/problematic? Feedback would be appreciated. Thanks, Dave //===- llvm/Support/VTable.h - LLVM-style

> On Oct 30, 2019, at 5:57 PM, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 10/30/2019 03:09 AM, Stephan Bergmann via llvm-dev wrote: >> You can apparently leave comments on GitHub commits (instead of commenting at Phabricator, or directly sending a reply to the relevant commit mailing list and relevant CCs). I once accidentally did that myself