similar to: [LLVMdev] Flag to print vectorized loops

----- Original Message ----- > From: "Sebastian Pop" <spop at codeaurora.org> > To: "Nadav Rotem" <nrotem at apple.com>, llvm-commits at cs.uiuc.edu, llvmdev at cs.uiuc.edu > Sent: Monday, November 26, 2012 5:20:47 PM > Subject: [llvm-commits] Flag to print vectorized loops > > Hi, > > Nadav Rotem wrote: > > > > On Nov 26,

Nadav Rotem wrote: > I don't think that printing to stdout is the right thing to do. I think that > we need to go through the clang driver. I'm not sure I understand exactly what you are suggesting: could you please give some more details? Do you mean that we should use clang's diagnostic infrastructure to report these messages? Thanks, Sebastian -- Qualcomm Innovation

Hi Sebastian, Thanks for looking at this. I don't think that printing to stdout is the right thing to do. I think that we need to go through the clang driver. Nadav On Nov 26, 2012, at 3:20 PM, Sebastian Pop <spop at codeaurora.org> wrote: > Hi, > > Nadav Rotem wrote: >> >> On Nov 26, 2012, at 1:46 PM, Sebastian Pop <spop at codeaurora.org> wrote:

On Nov 26, 2012, at 3:46 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > In my opinion, what we really need is an interface that the frontend can use to get information from the backend optimizers. Then the frontend can display this information to users in an appropriate way. I agree. > Furthermore, this information should be structured (we already have a YAML parser, so that

> IMO, the right way to build this is something like > "InlineAsmDiagnosticHandler" in LLVMContext (but hopefully better, and more > structured :) Hey Chris, Did you catch my suggestion in reply to Hal, about maybe generalizing Clang's diagnostics infrastructure up into LLVM? Your reply seems along the same lines. It seems like a natural fit to reuse that rather than make

On Nov 26, 2012, at 6:00 PM, Nadav Rotem <nrotem at apple.com> wrote: > > On Nov 26, 2012, at 3:46 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> > >> In my opinion, what we really need is an interface that the frontend can use to get information from the backend optimizers. Then the frontend can display this information to users in an appropriate way. >

On Mon, Nov 26, 2012 at 6:26 PM, Sean Silva <silvas at purdue.edu> wrote: >> IMO, the right way to build this is something like >> "InlineAsmDiagnosticHandler" in LLVMContext (but hopefully better, and more >> structured :) > > Hey Chris, > > Did you catch my suggestion in reply to Hal, about maybe generalizing > Clang's diagnostics

Hello all, Thanks for the comments. Attached is a new version with Tobias' and Sebastian's (final?) comments addressed. Any further comments are appreciated. Nadav suggested a request for comments in llvmdev before committing it. In order to describe the current idea of the parallel loop metadata, I think it's easiest to just copy-paste the documentation I wrote for this patch so

On Feb 7, 2013, at 10:55 AM, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: > Hi Nadav, > > On 02/07/2013 07:46 PM, Nadav Rotem wrote: >> Pekka suggested that we add two kind of metadata: llvm.loop.parallel >> (attached to each loop latch) and llvm.mem.parallel (attached to each memory >> instruction!). I think that the motivation for the first

On May 23, 2013, at 8:52 AM, "Redmond, Paul" <paul.redmond at intel.com> wrote: > > !0 = metadata !{ metadata !1, metadata !2 } > !1 = metadata !{ metadata !"llvm.loop.parallel" } > !2 = metadata !{ metadata !"llvm.vectorization.vector_width", i32 8 } > > I'm not even sure you would need the llvm.loop.parallel anymore since the

Nadav Rotem wrote: > > On Feb 7, 2013, at 10:55 AM, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: > > > Hi Nadav, > > > > On 02/07/2013 07:46 PM, Nadav Rotem wrote: > >> Pekka suggested that we add two kind of metadata: llvm.loop.parallel > >> (attached to each loop latch) and llvm.mem.parallel (attached to each memory > >>

----- Original Message ----- > > Hi Nadav, > > that's the whole point of it. I can't in general make the index > calculation simpler. The example given is the simplest non-trivial > index function that is needed. It might well be that it's that > simple that the index calculation in this case can be thrown aways > altogether and - as you say - be replaced by

Tom (and Andy, Owen, Evan, Nadav), I'd like the following commits placed into the 3.4.1 branch. I've attempted to sort this list by code owner: Andrew Trick: r203719 - PR17473 r203725 - This test need the X86 backend, move it to the X86 sub directory. [adjusts the test location from r203719] r202273 - Fix PR18165: LSR must avoid scaling factors that exceed the limit on truncated use.

On Aug 20, 2013, at 10:22 , Nadav Rotem <nrotem at apple.com> wrote: > Can you send the IR of the function ? Attached is the -O0 and -O3 IR -------------- next part -------------- A non-text attachment was scrubbed... Name: vselect_optimized.ll Type: application/octet-stream Size: 1545 bytes Desc: not available URL:

Hi, Last week I wrote llvm-dev and presented data that shows how enabling the vectorizer on -Os can improve the performance of many workloads and that it has negligible effects on code size. I also added a command line switch to make it easier for people to benchmark the vectorizer using -Os directly from clang without changing LLVM. Has anyone done any benchmarks on -Os + vectorization ?

Hi, Yes. On Sandybridge 256-bit loads/stores are double pumped. This means that they go in one after the other in two cycles. On Haswell the memory ports are wide enough to allow a 256bit memory operation in one cycle. So, on Sandybridge we split unaligned memory operations into two 128bit parts to allow them to execute in two separate ports. This is also what GCC and ICC do. It is very

Eli, I understand the need to widen unsigned types. However, I ran into a problem with the current GEP/subscript that clang has. AVX2 gather instructions rely on a 64-bit base pointer and a vector of 32-bit indices. Usually, when vectorizing programs, it is possible to detect that the GEP base pointer is uniform and that the index is variant (and needs to be vectorized). This works really nice

On Mon, 25 Jun 2012 05:45:57 +0000 "Rotem, Nadav" <nadav.rotem at intel.com> wrote: > Hi Hal, > > Why do say that the type v4i64 is broken ? You can specify that this > type has no legal operations and the codegen will lower ("legalize") > them to something that works on your platform. For example, the AND operation is really only an AND operation

On 31/10/13 13:34, Hal Finkel wrote: > ----- Original Message ----- >> Hi Nadav, >> >> that's the whole point of it. I can't in general make the index >> calculation simpler. The example given is the simplest non-trivial >> index function that is needed. It might well be that it's that >> simple that the index calculation in this case can be

Hi Dmitry, On 01/09/2013 03:48 PM, Dmitry Mikushin wrote: > Hi Sebastian, > > This kind of analysis is a pretty complex problem in general case. > Consider, for instance, function "f" has nested calls of other functions > with "side effects", meaning they could potentially change the contents of > "in" or "out" indirectly. For this