similar to: [LLVMdev] selection dag speedups / llc speedups

Here are some recent stats of the fast vs local vs linear scan at O0 on "opt -std-compile-opts" processed bitcode files. The fast regalloc is still certainly faster at codegen than local with such bitcode files. Let me know if the link doesn't work: https://spreadsheets.google.com/a/google.com/ccc?key=0At5EJFcCBf-wdDgtd2FoZjU4bFBzcFBtT25rQkgzMEE&hl=en Misc stuff: I ran into an

On May 14, 2010, at 11:24 AM, Jan Voung wrote: > I'm sure this has been asked many times, but is there current work on decreasing the time taken by the DAG-based instruction selector, or the other phases of llc? I am just beginning to dive into LLVM, and I am interested in compile-time reductions that do not reduce code quality dramatically. For example, simply switching on

On May 18, 2010, at 12:07 PM, Jan Voung wrote: > Here are some recent stats of the fast vs local vs linear scan at O0 on "opt -std-compile-opts" processed bitcode files. The fast regalloc is still certainly faster at codegen than local with such bitcode files. Let me know if the link doesn't work: > >

Per subject, this patch adding an additional pass to handle vector operations; the idea is that this allows removing the code from LegalizeDAG that handles illegal types, which should be a significant simplification. There are still some issues with this patch, but does the approach look sane? -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp

On May 17, 2010, at 9:09 PM, Rafael Espindola wrote: >> The fast and local register allocators are meant to be used on unoptimized code, a 'Debug build'. While they do work on optimized code, they do not give good results. Their primary goal is compile time, not code quality. > > Yes, we have a somewhat uncommon use case. It is fine to spend time > optimizing bitcode (LTO

> The fast and local register allocators are meant to be used on unoptimized code, a 'Debug build'. While they do work on optimized code, they do not give good results. Their primary goal is compile time, not code quality. Yes, we have a somewhat uncommon use case. It is fine to spend time optimizing bitcode (LTO is a OK), but we want to make the final IL -> Executable translation

On Wed, May 20, 2009 at 1:19 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > Per subject, this patch adding an additional pass to handle vector > operations; the idea is that this allows removing the code from > LegalizeDAG that handles illegal types, which should be a significant > simplification.  There are still some issues with this patch, but does > the approach

On May 20, 2009, at 9:14 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 5:26 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: >> >>> Can you explain why you chose the approach of using a new pass? >>> >>> I pictured removing LegalizeDAG's type

I was able to compile LLVM on windows (llvm2.3) using Visual studio. When I type llc -help command, I do not see -view-isel-dags option (http://llvm.org/docs/CodeGenerator.html document mentions about it). Is this option is supported on Windows (or Cygwin) build? Thanks a bunch, -Sanjay -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Aug 22, 2008, at 12:10 PM, Sanjay Soman wrote: > I was able to compile LLVM on windows (llvm2.3) using Visual studio. > When I type llc -help command, I do not see -view-isel-dags option (http://llvm.org/docs/CodeGenerator.html > document mentions about it). Is this option is supported on Windows > (or Cygwin) build? > Does it show up when you use -help-hidden? -bw

Yea. I think AMD chains the node they're expanding into, but they don't chain it into an _existing_ chain. e.g. adding A->B to the DAG is ok. But adding A->B and next C->D with B->C is the problem. I appreciate the input On Thu, Jul 16, 2020 at 2:04 PM Matt Arsenault <arsenm2 at gmail.com> wrote: > > > > On Jul 16, 2020, at 17:00, Hendrik Greving

Dear All, I would like to know if the Voung test (Voung; Econometrica, 1989) to compare two non-nested regression models has been implemented in R. Thanks in advance for your assistance, mirko [[alternative HTML version deleted]]

newbee here. What's the difference between glue and chain? Why can't we add chains to any node we want? On Fri, Jul 17, 2020, 10:25 PM Björn Pettersson A via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Still sounds to me as Glue might help (as already proposed by Craig), but > maybe I’ve misunderstood something. > > > > Another option is to do a simple

<br>

Hello, Tim, Thank you for your advice. Indeed, the problem with "LLVM ERROR: Cannot select" was a false predicate that should have been true. I solved the problem by simply making the C++ function implementing the TableGen predicate used in my store instruction (very similar to the selectIntAddrMSA predicate from the Mips back end) return true instead of false. But

I have been working on improvements to TableGen's DAG Isel matcher backend. This has led me to thinking about ways to speed up the compile-time interpreter of the instruction selection matcher table. Is this worth my time, given Fast Isel and the upcoming Global Isel selector?

I did it by code preparing into an intrinsic that has side effects. Pseudo instruction would work as well. I'm not sure if glue would help, since the nodes A->B, C->D from example above are not necessarily adjacent. More hooks into the selection DAG builder may be an idea for a LLVM extension. For example in this case, custom allowing for a node to be built with an existing chain would

On 26 September 2012 01:08, Jan Voung <jvoung at chromium.org> wrote: > - Forward references will create negative-valued ids (which end up being > written out as large 32-bit integers, as far as I could tell). Can you use an SLEB-like representation? It's probably not going to be backwards compatible, but if there isn't an SLEB/ULEB representation in bitcode, I'd say

Oops, sorry hit send too early -- meant to just make a draft email. I'm still looking through, but so far I hadn't seen many of its methods being used... On Fri, Oct 26, 2012 at 4:37 PM, Jan Voung <jvoung at chromium.org> wrote: > > -------------- next part -------------- An HTML attachment was scrubbed... URL:

Are you talking about the type checking done in CodeGenDAGPatterns.cpp? Is it easy to post an example? At 11/18/2020 01:55 PM, Thomas Lively wrote: >Hi Paul, > >I think this would be time well spent. At least in the WebAssembly backend, the vast majority of our ISel work is still done with DAG ISel. I know this is different from the performance work you have in mind, but one of my