search for: llvmpipe

...t; > I actually prefer that the Scalarizer would not touch TTI at all because > I view scalarization a canonicalization phase for DSLs, much like SROA > breaks structs. That's what Pekka is thinking of using it for, but it wasn't the reason I wrote it. The original motivation was llvmpipe, which is a rasteriser rather than a DSL compiler. The motivation wasn't to canonicalise, it was to do the same thing that codegen currently does, but in a better place from an optimisation perspective. You said in an earlier message: Other users of LLVM (such as OpenCL JITs) do scalarize...

Hi Richard, The discussion on llvmpipe is irrelevant. llvmpipe has its own pass manager and optimization pipe, it is not a C compiler. Nadav On Nov 15, 2013, at 3:26 AM, Richard Sandiford <rsandifo at linux.vnet.ibm.com> wrote: > Nadav Rotem <nrotem at apple.com> writes: >> On Nov 14, 2013, at 2:32 PM, Richa...

Hello, Can i use llvmpipe for ARM cortexA-9 target ?? If it is already proven then send me any link or hint with details to test. Thanks..

On Nov 14, 2013, at 2:32 PM, Richard Sandiford <rsandifo at linux.vnet.ibm.com> wrote: > Richard Sandiford <rsandifo at linux.vnet.ibm.com> writes: >> Are you worried that adding it to PMB will increase compile time? >> The pass exits very early for any target that doesn't opt-in to doing >> scalarisation at the IR level, without even looking at the function.

Richard Sandiford <rsandifo at linux.vnet.ibm.com> writes: > Are you worried that adding it to PMB will increase compile time? > The pass exits very early for any target that doesn't opt-in to doing > scalarisation at the IR level, without even looking at the function. As an alternative, adding Scalarizer and InstCombine passes to SystemZPassConfig::addIRPasses() would probably

https://bugs.freedesktop.org/show_bug.cgi?id=99335 Bug ID: 99335 Summary: nouveau graphics often freezes when using KDE Plasma 5 Product: Mesa Version: 12.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/DRI/nouveau

...r to many scalar > > instructions. I found llvm doesn't have DSE in codegen , right? > > > > > > Is there a pass which can break down vector operation to scalars? > > I wanted the same thing for SystemZ, which doesn't have vectors, > in order to improve the llvmpipe code. FWIW, here's what I have locally. > > It is able to decompose loads and stores, but I found in the llvmpipe case > that this made things worse with TBAA, because DAGCombiner::GaterAllAliases > has some fairly strict limits. So I disabled that by default; use > -decompose-...

...s for a scalar > processor. > > i think a good solution for llvm is in codegen. Many compiler has codegen > optimizer. A DSE is good enough. > > Which posted patch about TBAA? you have yet another solution except > decompose-vectors? Ah, no, the TBAA thing is separate really. llvmpipe generally operates on 4 rows at a time, so some functions end up with patterns like: load <16 x i8> row0 ... load <16 x i8> row1 ... load <16 x i8> row2 ... load <16 x i8> row3 ... ... do stuff ... store <16 x i8> row0 ... store <16 x i8> ro...

I am trying to understand the s3tc init code as nv50 gallium has a problem with that. It looks like some drivers (r300g and llvmpipe) actually inits s3tc in two places : ./src/mesa/main/texcompress_s3tc.c _mesa_init_texture_s3tc() ./src/gallium/auxiliary/util/u_format_s3tc.c util_format_s3tc_init() Here is an extract of the backtrace calls while loading fgfs on llvmpipe : driCreateScreen -> llvmpipe_create_screen -> util_...

...-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/docs/source/screen.rst | 3 +++ src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c | 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + src/gallium/drivers/r300/r300_screen.c | 1 + src/gallium/drivers/r600/r600_pipe.c...

...gt; --- >> src/gallium/docs/source/screen.rst | 3 +++ >> src/gallium/drivers/freedreno/freedreno_screen.c | 1 + >> src/gallium/drivers/i915/i915_screen.c | 1 + >> src/gallium/drivers/ilo/ilo_screen.c | 1 + >> src/gallium/drivers/llvmpipe/lp_screen.c | 1 + >> src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + >> src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + >> src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + >> src/gallium/drivers/r300/r300_screen.c | 1 + >> src...

...; > > i think a good solution for llvm is in codegen. Many compiler has codegen > > optimizer. A DSE is good enough. > > > > Which posted patch about TBAA? you have yet another solution except > > decompose-vectors? > > Ah, no, the TBAA thing is separate really. llvmpipe generally operates > on 4 rows at a time, so some functions end up with patterns like: > > load <16 x i8> row0 ... > load <16 x i8> row1 ... > load <16 x i8> row2 ... > load <16 x i8> row3 ... > ... do stuff ... > store <16 x i8&g...

...which means we have to lower vector to many scalar > instructions. I found llvm doesn't have DSE in codegen , right? > > > Is there a pass which can break down vector operation to scalars? I wanted the same thing for SystemZ, which doesn't have vectors, in order to improve the llvmpipe code. FWIW, here's what I have locally. It is able to decompose loads and stores, but I found in the llvmpipe case that this made things worse with TBAA, because DAGCombiner::GaterAllAliases has some fairly strict limits. So I disabled that by default; use -decompose-vector-load-store to ree...

Hi, LLVM community, I write some code in hand using LLVM IR. for simplicity, I write them in <4 x float>. now I found some stores for elements are useless. for example, If I store {0.0, 1.0, 2.0, 3.0} to a <4 x float> %a. maybe only %a.xy is alive in my program. our target doesn't feature SIMD instruction, which means we have to lower vector to many scalar instructions. I found

...t alum.mit.edu> > --- > src/gallium/docs/source/screen.rst | 3 +++ > src/gallium/drivers/freedreno/freedreno_screen.c | 1 + > src/gallium/drivers/i915/i915_screen.c | 1 + > src/gallium/drivers/ilo/ilo_screen.c | 1 + > src/gallium/drivers/llvmpipe/lp_screen.c | 1 + > src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + > src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + > src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + > src/gallium/drivers/r300/r300_screen.c | 1 + > src/gallium/drivers/r60...

...src/gallium/docs/source/screen.rst | 3 +++ >>> src/gallium/drivers/freedreno/freedreno_screen.c | 1 + >>> src/gallium/drivers/i915/i915_screen.c | 1 + >>> src/gallium/drivers/ilo/ilo_screen.c | 1 + >>> src/gallium/drivers/llvmpipe/lp_screen.c | 1 + >>> src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + >>> src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + >>> src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + >>> src/gallium/drivers/r300/r300_screen.c | 1...

On 25 October 2013 11:06, Richard Sandiford <rsandifo at linux.vnet.ibm.com>wrote: > I wanted the same thing for SystemZ, which doesn't have vectors, > in order to improve the llvmpipe code. > Hi Richard, This is a nice patch. I was wondering how hard it'd be to do that, and it seems that you're catching lots of corner cases. My interest is also due to converting odd vectors into scalars, but to convert them again to CPU vectors, say from OpenCL to NEON code. It w...

...me infrastructure for any situation in which you know that two accesses can't overlap, even if that doesn't really map to "type"s in the language sense. So it's more than just C++ (or other languages, like LangRef.rst says). In my case, I'm using TBAA for IR generated by llvmpipe. The information I'm adding isn't really related to the C types in llvmpipe (or gallium/mesa generally). It just says that two accesses can't overlap because they refer to different arrays, or different rows/slices of the same array. > Do you mean that you can make use of TBAA to...

...pose the addition of a new SystemZ backend to the LLVM and Clang code base. We're interested in this for the same reason we've been interested in the PowerPC back-end recently: to enable packages in upcoming enterprise Linux distributions that need LLVM support (e.g. 3D desktop support via llvmpipe). Now, I understand that a SystemZ backend used to be part of LLVM for a while, but has been removed (due to lack of maintenance, it would appear). While the backend provided by this set of patches is originally based on that old SystemZ backend, it has been significantly rewritten and many of the...

...ll. :-) I was just assuming that we'd want to keep vector operations together if there's native support. E.g. ISTR comments about not wanting to rewrite vec_selects because it can be hard to synthesise optimal sequences from a single canonical form. But I might have got that wrong. Also, llvmpipe uses intrinsics for some things, so it might be strange if we decompose IR operations but leave the intriniscs alone. I'd half wondered whether, as an extension, the pass should split wide vectors into supported widths. I hadn't thought about the possiblity of decomposing everything and t...