search for: optimizability

Hi Mark, This will workaround the problem of "default" branch restriction on the switch instruction. The trouble with this technique is that it will trump later optimization phases such as constant propagation. When a block was part of a case, because of the knowledge of the case value, the block was a candidate for better optimization. However, when we move the body of the case into

I think this is a missed optimization, but maybe I'm missing some significant piece of knowledge(!) as to why this might not be optimizable :) Test case... int A; // some global int B; // some global void Test(int *Out) { *Out = A; // Can't this be optimized away? *Out = B; }; The LLVM backend (tested 3.1 and 3.0 online demo) doesn't optimize

On 11/11/2015 9:36 AM, Hal Finkel wrote: > ----- Original Message ----- >> From: "Krzysztof Parzyszek" <kparzysz at codeaurora.org> >> >> Yeah, the remark about devices I made in my post was a result of a >> "last-minute" thought to add some rationale. It doesn't actually >> apply >> to SROA, since there are no devices that are

On Jul 17, 2013, at 10:09 PM, Milind Chabbi <Milind.Chabbi at rice.edu> wrote: > Hi Mark, > > This will workaround the problem of "default" branch restriction on > the switch instruction. The trouble with this technique is that it > will trump later optimization phases such as constant propagation. > When a block was part of a case, because of the knowledge of

Hi, If the function was called Test(&B) then the first store would affect the second load. Tim. On Fri, Nov 16, 2012 at 11:58 AM, AnonW <wayne.phillips at gmail.com> wrote: > I think this is a missed optimization, but maybe I'm missing some significant > piece of knowledge(!) as to why this might not be optimizable :) Test > case... > > int A; // some global

Hi Milind, Maybe you could annotate the default case value as metadata to the swith instruction. Thanks Hongbin On Thu, Jul 18, 2013 at 1:09 PM, Milind Chabbi <Milind.Chabbi at rice.edu>wrote: > Hi Mark, > > This will workaround the problem of "default" branch restriction on > the switch instruction. The trouble with this technique is that it > will trump later

...ng of > certain constructs. I don't think that we currently have any documentation > targeted at language frontend writers; I would really like to see this > document evolve into that. > > E.g., what are the different ways to do lambdas and what are their > tradeoffs regarding optimizability, etc.; or a discussion of the various > function attributes (e.g. noalias) which are vital for getting the best > performance out of the optimizers (many languages semantically don't have > aliasing issues (or fewer than C/C++ at least!), and this needs to be > communicated to the o...

Hongbin Can you elaborate more on your suggestion? I am not sure I fully understand what you suggested. -Milind On Wed, Jul 17, 2013 at 11:11 PM, Hongbin Zheng <etherzhhb at gmail.com> wrote: > Hi Milind, > > Maybe you could annotate the default case value as metadata to the swith > instruction. > > Thanks > Hongbin > > > On Thu, Jul 18, 2013 at 1:09 PM,

Recently I posted a patch to migrate certain GEPs between basic blocks in cases where doing so would improve the ability of instcombine to merge into more complicated addressing mode (r209049 and r209065). After some build to failures it was rolled back. I now have a patch that no longer causes the regressions I was seeing, but it also no longer can optimize the case I was trying to optimize. As

...ecisions regarding the lowering of certain constructs. I don't think that we currently have any documentation targeted at language frontend writers; I would really like to see this document evolve into that. E.g., what are the different ways to do lambdas and what are their tradeoffs regarding optimizability, etc.; or a discussion of the various function attributes (e.g. noalias) which are vital for getting the best performance out of the optimizers (many languages semantically don't have aliasing issues (or fewer than C/C++ at least!), and this needs to be communicated to the optimizer; currently...

James Henderson via llvm-dev <llvm-dev at lists.llvm.org> writes: > Maybe it's just because I work in code around the binary file formats > almost exclusively, but unsigned (or more often uint64_t) is FAR more > common than int everywhere I go. I don't have time right now to read > up on the different links you provided, and I expect this is covered > in them, but it

Hi,     I am planning to follow the steps to install LLVM for the ARM-target (Processor: Xscale, Architecture: armv5te):   1. Install binutils-2.21 (downloaded from gnu.org)   Steps:   $ ./configure --target=arm-unknown-linux-gnueabi --program-prefix=arm- --prefix =/llvm/arm --with-sysroot=/llvm/arms/sys-root   $ make   $ make install   2. Install LLVM   Steps   $ ../llvm-src/configure

...onstructs. I don't think that we currently have any documentation >> targeted at language frontend writers; I would really like to see this >> document evolve into that. >> >> E.g., what are the different ways to do lambdas and what are their >> tradeoffs regarding optimizability, etc.; or a discussion of the various >> function attributes (e.g. noalias) which are vital for getting the best >> performance out of the optimizers (many languages semantically don't have >> aliasing issues (or fewer than C/C++ at least!), and this needs to be >> commu...

I have some LLVM IR after the optimization passes defined in createStandardModulePasses with the optimization level set to 3. It contains what appears to me to be an easily optimizable branch statement. In particular, note in the code below that at the end of the "loop" BasicBlock that there is a conditional branch where in the false case, it branches to the label

On Jan 1, 2011, at 8:29 PM, akramul azim wrote: > Hi, > I am planning to follow the steps to install LLVM for the ARM-target (Processor: Xscale, Architecture: armv5te): > > 1. Install binutils-2.21 (downloaded from gnu.org) > > Steps: > > $ ./configure --target=arm-unknown-linux-gnueabi --program-prefix=arm- --prefix > =/llvm/arm

Hi Milind, My suggestion just for your concern that if you eliminate the default block, a block associated with a case value will become the default block of the swhich instruction, since a switch instruction always requires a default block. But when a block associated with a case value become the default block, the associated case value is lost and may confuse the later optimizations such as

> On Jul 23, 2018, at 3:40 PM, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 23 July 2018 at 11:56, Arsenault, Matthew via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >> Hi, >> >> >> The specification for the llvm.minnum/llvm.maxnum intrinsics is too unclear >> right

The thread here should help. http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-May/031624.html On May 28, 2010, at 6:35 AMPDT, Curtis Faith wrote: > I have some LLVM IR after the optimization passes defined in createStandardModulePasses with the optimization level set to 3. It contains what appears to me to be an easily optimizable branch statement. > > In particular, note in the code

...''content?'':sioc+''content'', limit:7, offset:0, order: {p:''date'',d:''desc''}} as well as plain keyword search of literals. the underlying indices are visible in and implemented using the store itself. designed with optimizability / hackability in mind, to invent the partitioning/distribution to meet your needs, adjust the editing method to send all edits to an Utu chan or RDF-over-JSON-over-Jabber to viewers, mirror data to a beastly SPARQL engine, etc. http://whats-your.name/e/e.tar.gz water is the mongrel layer. it...

> On Feb 15, 2016, at 4:25 PM, Philip Reames <listmail at philipreames.com> wrote: > > After reading https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/ <https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/>., I jotted down a couple of thoughts of my own here: http://www.philipreames.com/Blog/2016/02/15/quick-thoughts-on-webkits-b3/