Displaying 20 results from an estimated 20000 matches similar to: "[LLVMdev] Flag to print vectorized loops"
2012 Nov 26
0
[LLVMdev] [llvm-commits] 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,
2012 Nov 26
1
[LLVMdev] Flag to print vectorized loops
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
2012 Nov 26
0
[LLVMdev] Flag to print vectorized loops
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:
2012 Nov 27
2
[LLVMdev] [llvm-commits] Flag to print vectorized loops
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
2012 Nov 27
3
[LLVMdev] [llvm-commits] Flag to print vectorized loops
> 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
2012 Nov 27
0
[LLVMdev] [llvm-commits] Flag to print vectorized loops
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.
>
2012 Nov 27
0
[LLVMdev] [llvm-commits] Flag to print vectorized loops
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
2013 Feb 04
2
[LLVMdev] RFC: [PATCH] parallel loop metadata
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
2013 Feb 07
4
[LLVMdev] Parallel Loop Metadata
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
2013 May 23
3
[LLVMdev] LLVM Loop Vectorizer puzzle
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
2013 Feb 08
0
[LLVMdev] Parallel Loop Metadata
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
> >>
2013 Oct 31
3
[LLVMdev] loop vectorizer misses opportunity, exploit
----- 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
2014 Apr 08
9
[LLVMdev] 3.4.1 Release Plans
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.
2013 Aug 20
3
[LLVMdev] Failure to optimize vector select
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:
2013 Jun 14
5
[LLVMdev] Enabling the vectorizer for -Os -- ping
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 ?
2013 Jul 10
3
[LLVMdev] unaligned AVX store gets split into two instructions
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
2011 Dec 10
2
[LLVMdev] [cfe-dev] GEP index type
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
2012 Jun 25
2
[LLVMdev] Boolean floats and v4i1
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
2013 Oct 31
0
[LLVMdev] loop vectorizer misses opportunity, exploit
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
2013 Jan 09
3
[LLVMdev] Pointer "data direction"
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