search for: gbiv

...yCSE, the test run command line or something else not related to the MemorySSA code proper. -- Geoff Berry Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From: George Burgess [mailto:gbiv at google.com] Sent: Wednesday, April 20, 2016 3:29 PM To: Geoff Berry <gberry at codeaurora.org> Cc: Daniel Berlin <dberlin at dberlin.org>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [LICM][MemorySSA] Converting LICM pass to use MemorySSA to avoid AliasSet collapse issu...

...Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From: Daniel Berlin [mailto:dberlin at dberlin.org] Sent: Wednesday, April 20, 2016 1:06 PM To: Geoff Berry <gberry at codeaurora.org>; George Burgess <gbiv at google.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [LICM][MemorySSA] Converting LICM pass to use MemorySSA to avoid AliasSet collapse issue On Wed, Apr 20, 2016 at 9:58 AM, Geoff Berry <gberry at codeaurora.org <mailto:gberry at codeaurora.org> > wr...

Hello LLVMDev, I'm George, an intern for Google who will be working on LLVM. Currently, I'm starting to implement a set-based Alias Analysis algorithm for LLVM, which looks like it may be more accurate than Steensgard's, and can be constructed in approximately nlog(n) time and linear space (n = number of memory locations; queries happen in constant time). It will most likely be

...un on a directory. Then for each subsystem you can say in your commit "I ran scripts/fix_whatever.py on this subdir." Then others can help you drive the tree wide cleanup. Then we can enable -Wunreachable-code-break either by default, or W=2 right now might be a good idea. Ah, George (gbiv@, cc'ed), did an analysis recently of `-Wunreachable-code-loop-increment`, `-Wunreachable-code-break`, and `-Wunreachable-code-return` for Android userspace. From the review: ``` Spoilers: of these, it seems useful to turn on -Wunreachable-code-loop-increment and -Wunreachable-code-return by d...

On Mon, Jan 14, 2019 at 4:51 PM Chandler Carruth <chandlerc at gmail.com> wrote: > > On Mon, Jan 14, 2019, 15:59 Mehdi AMINI <joker.eph at gmail.com wrote: > >> >> >> On Mon, Jan 14, 2019 at 9:36 AM Chandler Carruth via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> While I'm very interested in the end result here, I have

Hi Daniel, Thanks for the info. I’ve started looking into converting EarlyCSE to use MemorySSA first since 1) I don’t think it needs any additional MemorySSA update API and 2) the particular case I’m looking at needs EarlyCSE to catch more load cases before LICM to be profitable. I have a prototype working, but have run into two issues: 1) readonly calls are treated as clobbers by

From: Tom Rix <trix at redhat.com> This is a upcoming change to clean up a new warning treewide. I am wondering if the change could be one mega patch (see below) or normal patch per file about 100 patches or somewhere half way by collecting early acks. clang has a number of useful, new warnings see

From: Tom Rix <trix at redhat.com> This is a upcoming change to clean up a new warning treewide. I am wondering if the change could be one mega patch (see below) or normal patch per file about 100 patches or somewhere half way by collecting early acks. clang has a number of useful, new warnings see