similar to: [LLVMdev] Simple NEON optimization

On Nov 12, 2010, at 7:23 AM, Renato Golin wrote: > Hi folks, me again, > > So, I want to implement a simple optimization in a NEON case I've seen > these days, most as a matter of exercise, but it also simplifies (just > a bit) the code generated. > > The case is simple: > > uint32x2_t x, res; > res = vceq_u32(x, vcreate_u32(0)); > > This

On 12 November 2010 17:52, Bob Wilson <bob.wilson at apple.com> wrote: > I recommend implementing this as a target-specific DAG combine optimization.  We already have target-specific DAG nodes for the relevant NEON comparison operations (ARMISD::VCEQ, etc. -- see ARMISelLowering.h) as well as the vmov (ARMISD::VMOVIMM).  You just need to teach the DAG combiner how to fold them together.

Is this related to Owen's patch r118453? Evan On Nov 12, 2010, at 10:42 AM, Renato Golin wrote: > On 12 November 2010 17:52, Bob Wilson <bob.wilson at apple.com> wrote: >> I recommend implementing this as a target-specific DAG combine optimization. We already have target-specific DAG nodes for the relevant NEON comparison operations (ARMISD::VCEQ, etc. -- see

On Oct 14, 2013, at 3:27 AM, Zakk <zakk0610 at gmail.com> wrote: > Hi all, > I meet this problem when compiling the TREAM benchmark (http://www.cs.virginia.edu/stream/FTP/Code/) with enable-misched > > The small function will be scheduled as good code, but if opt inline this function, the inline part will be scheduled as bad code. A bug for this is welcome. Pretty soon, I’ll

Hi Duncan, I also thought it was a bug, especially since it worked with LLVM 3.0, but since it is not defined by ABI, I was not sure if I need to submit it as a BUG. I wanted to be sure that it is an actual BUG before submitting it and got the not-a-bug answer. Here is a small example to reproduce the problem I'm experiencing: ; ModuleID = 'bugparam.ll' target datalayout =

Hi all, I meet this problem when compiling the TREAM benchmark ( http://www.cs.virginia.edu/stream/FTP/Code/) with enable-misched The small function will be scheduled as good code, but if opt inline this function, the inline part will be scheduled as bad code. so I rewrite a simple code as attached link (foo.c), and compiled with two different methods: *method A:* *$clang -O3 foo.c -static -S

Hi Sebastien, > I also thought it was a bug, especially since it worked with LLVM 3.0, but since it is not defined by ABI, I was not sure if I need to submit it as a BUG. yes it is a bug. > I wanted to be sure that it is an actual BUG before submitting it and got the not-a-bug answer. I didn't read Nadav's reply as saying there was no bug, in fact he explicitly said in his email

On Jul 1, 2013, at 11:52 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Mon, Jul 1, 2013 at 11:30 AM, Quentin Colombet <qcolombet at apple.com> wrote: > Hi, > > ** Problematic ** > I am looking for advices to share some logic between DAG combine and target lowering. > > Basically, I need to know if a bitcast that is about to be inserted during target

Hi, ** Problematic ** I am looking for advices to share some logic between DAG combine and target lowering. Basically, I need to know if a bitcast that is about to be inserted during target specific isel lowering will be eliminated during DAG combine. Let me know if there is another, better supported, approach for this kind of problems. ** Motivating Example ** The motivating example comes

On Mon, Jul 1, 2013 at 11:30 AM, Quentin Colombet <qcolombet at apple.com>wrote: > Hi, > > ** Problematic ** > I am looking for advices to share some logic between DAG combine and > target lowering. > > Basically, I need to know if a bitcast that is about to be inserted during > target specific isel lowering will be eliminated during DAG combine. > > Let me

On Mon, Jul 1, 2013 at 1:33 PM, Quentin Colombet <qcolombet at apple.com>wrote: > On Jul 1, 2013, at 11:52 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > > On Mon, Jul 1, 2013 at 11:30 AM, Quentin Colombet <qcolombet at apple.com> > wrote: > >> Hi, >> >> ** Problematic ** >> I am looking for advices to share some logic between DAG

This would be best reported to Apple's Radar bug database at http://bugreport.apple.com/ but its whole website has been down for a while. I have a 100% reproducible Thumb-2 code generation error that occurs at all of the levels of optimization available in the Xcode 4.2 for Snow Leopard build settings GUI: -O0, -O1, -O2, -O3 and -Os. However the bad machine code only occurs in Release

From: Jyri Sarha <jsarha at ti.com> I optimized Speex resampler for NEON capable ARM CPUs. The first patch should speed up resampling on any platform that can spare the increased memory usage. It would be nice to have these merged to the master branch. Please let me know if there is anything I can do to help the the merge. The patches have been rebased on top of master branch in

Hi Sebastien, > Thanks for the quick answer, how do I know which type is legal/illegal with respect to calling convention ? the code generators are supposed to produce working code no matter what the parameter type is. The fact that the ARM ABI doesn't specify how <2 x i8> is passed just means that the code generators can pass it using whatever technique it feels like (since it

Hi Andy, thanks for your help!! The scheduled code by method A is same as B when using the new machine model. it's make sense, but there is the another problem, the scheduled code is badly. load/store instruction always reuse the same register Source: #define N 2000000 static double b[N], c[N]; void Scale () { double scalar = 3.0; for (int j=0;j<N;j++) b[j] =

Hi all, I’m not sure if this is the right list, so apologies if not. Doing some profiling I noticed some of my hand-tuned matrix multiply code with NEON intrinsics was much slower through a C++ template wrapper vs calling the intrinsics function directly. It turned out clang/LLVM was unable to eliminate a temporary even though the case seemed quite straightforward. Unfortunately any loads

On 4 February 2013 18:25, Arnold Schwaighofer <aschwaighofer at apple.com>wrote: > For cases where this approach breaks really badly we could consider adding > a specialized api or parameters (like the type of a user/use). But we > should do so only as a last resort and backed by actual code that would > benefit from doing so. > Very sensible, more or less what I had in

On Nov 12, 2010, at 10:47 AM, Evan Cheng wrote: > Is this related to Owen's patch r118453? Oh, yes, it is indeed. I had forgotten about that already. Renato, this ought to be working already. Maybe you have an older version? > > Evan > > On Nov 12, 2010, at 10:42 AM, Renato Golin wrote: > >> On 12 November 2010 17:52, Bob Wilson <bob.wilson at apple.com>

Hi Rotem, Thanks for the quick answer, how do I know which type is legal/illegal with respect to calling convention ? Best Regards Seb > -----Original Message----- > From: Rotem, Nadav [mailto:nadav.rotem at intel.com] > Sent: Thursday, July 05, 2012 11:21 AM > To: Sebastien DELDON-GNB; llvmdev at cs.uiuc.edu > Subject: RE: Vector argument passing abi for ARM ? > > The

On 27 September 2010 18:19, Bob Wilson <bob.wilson at apple.com> wrote: > I'm not sure what you mean by this.  The llvm intrinsics and built-in vector operations use plain vectors regardless of the front-end.  The structures are only relevant for things like argument passing and copying -- you can't do anything else with them.  Can you post an example of the 5X IR code size that