search for: us70

...assume about it, a verifier pass is not supposed to change the code (or is it?) but in debug stream I see the following: Common predecessor: *** IR Dump After Loop-Closed SSA Form Pass *** for.body.us68: ; preds = %for.body.lr.ph.us81, %for.body.us68 %arrayidx.us70.phi = phi i8* [ %buf.0.ph, %for.body.lr.ph.us81 ], [ %arrayidx.us70.inc, %for.body.us68 ] %add.ptr4.us72.phi = phi i8* [ %add.ptr4.us72.gep, %for.body.lr.ph.us81 ], [ %add.ptr4.us72.inc, %for.body.us68 ] %i.043.us69 = phi i32 [ 0, %for.body.lr.ph.us81 ], [ %inc.us73, %for.body.us68 ] ... LV:...

...but in debug stream >> I see the >> following: >> >> Common predecessor: >> >> *** IR Dump After Loop-Closed SSA Form Pass *** >> for.body.us68: ; preds = >> %for.body.lr.ph.us81, %for.body.us68 >> %arrayidx.us70.phi = phi i8* [ %buf.0.ph, %for.body.lr.ph.us81 ], [ >> %arrayidx.us70.inc, %for.body.us68 ] >> %add.ptr4.us72.phi = phi i8* [ %add.ptr4.us72.gep, >> %for.body.lr.ph.us81 ], [ %add.ptr4.us72.inc, %for.body.us68 ] >> %i.043.us69 = phi i32 [ 0, %for.body.lr.ph.us81 ], [ %inc...

...sed to change the code (or is it?) but in debug stream > I see the > following: > > Common predecessor: > > *** IR Dump After Loop-Closed SSA Form Pass *** > for.body.us68: ; preds = > %for.body.lr.ph.us81, %for.body.us68 > %arrayidx.us70.phi = phi i8* [ %buf.0.ph, %for.body.lr.ph.us81 ], [ > %arrayidx.us70.inc, %for.body.us68 ] > %add.ptr4.us72.phi = phi i8* [ %add.ptr4.us72.gep, > %for.body.lr.ph.us81 ], [ %add.ptr4.us72.inc, %for.body.us68 ] > %i.043.us69 = phi i32 [ 0, %for.body.lr.ph.us81 ], [ %inc.us73, > %f...

...> >> following: > >> > >> Common predecessor: > >> > >> *** IR Dump After Loop-Closed SSA Form Pass *** > >> for.body.us68: ; preds = > >> %for.body.lr.ph.us81, %for.body.us68 > >> %arrayidx.us70.phi = phi i8* [ %buf.0.ph, %for.body.lr.ph.us81 ], [ > >> %arrayidx.us70.inc, %for.body.us68 ] %add.ptr4.us72.phi = phi i8* [ > >> %add.ptr4.us72.gep, > >> %for.body.lr.ph.us81 ], [ %add.ptr4.us72.inc, %for.body.us68 ] > >> %i.043.us69 = phi i32 [ 0, %for.body....

...ng: >>>> >>>> Common predecessor: >>>> >>>> *** IR Dump After Loop-Closed SSA Form Pass *** >>>> for.body.us68: ; preds = >>>> %for.body.lr.ph.us81, %for.body.us68 >>>> %arrayidx.us70.phi = phi i8* [ %buf.0.ph, %for.body.lr.ph.us81 ], [ >>>> %arrayidx.us70.inc, %for.body.us68 ] %add.ptr4.us72.phi = phi i8* [ >>>> %add.ptr4.us72.gep, >>>> %for.body.lr.ph.us81 ], [ %add.ptr4.us72.inc, %for.body.us68 ] >>>> %i.043.us69 = phi i32 [ 0,...

Liu, This is likely a better solution for you - you do not want to mess with the scheduler unless you really have to ;) Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Krzysztof Parzyszek > Sent:

On 1/7/2013 2:15 PM, Xu Liu wrote: > > This would be ideal. How can I do the instrumentation pass after the > instruction scheduling? You could derive your own class from TargetPassConfig, and add the annotation pass in YourDerivedTargetPassConfig::addPreEmitPass. This will add your annotation pass very late, just before the final code is emitted. If you're using the X86 target,

...; preds = %p.loop_body.lr.ph.us78, %p.loop_body.us65 %p_arrayidx.us69.phi = phi i16* [ %p_arrayidx.us69.gep, %p.loop_body.lr.ph.us78 ], [ %p_arrayidx.us69.inc, %p.loop_body.us65 ] %p.loopiv48.us66 = phi i32 [ 0, %p.loop_body.lr.ph.us78 ], [ %p.next_loopiv.us67, %p.loop_body.us65 ] %vector_ptr.us70 = bitcast i16* %p_arrayidx.us69.phi to <4 x i16>* %p.next_loopiv.us67 = add nsw i32 %p.loopiv48.us66, 4 <<<<<<<<<<<<<<<<<< IV %_p_vec_full.us71 = load <4 x i16>* %vector_ptr.us70, align 16 <<<<<<<<<&lt...

...s78, %p.loop_body.us65 > %p_arrayidx.us69.phi = phi i16* [ %p_arrayidx.us69.gep, > %p.loop_body.lr.ph.us78 ], [ %p_arrayidx.us69.inc, %p.loop_body.us65 > ] > %p.loopiv48.us66 = phi i32 [ 0, %p.loop_body.lr.ph.us78 ], [ > %p.next_loopiv.us67, %p.loop_body.us65 ] > %vector_ptr.us70 = bitcast i16* %p_arrayidx.us69.phi to <4 x i16>* > %p.next_loopiv.us67 = add nsw i32 %p.loopiv48.us66, 4 > <<<<<<<<<<<<<<<<<< > IV > %_p_vec_full.us71 = load <4 x i16>* %vector_ptr.us70, align 16 > <<<...

...t; > %p_arrayidx.us69.phi = phi i16* [ %p_arrayidx.us69.gep, > > %p.loop_body.lr.ph.us78 ], [ %p_arrayidx.us69.inc, %p.loop_body.us65 > ] > > %p.loopiv48.us66 = phi i32 [ 0, %p.loop_body.lr.ph.us78 ], [ > > %p.next_loopiv.us67, %p.loop_body.us65 ] > > %vector_ptr.us70 = bitcast i16* %p_arrayidx.us69.phi to <4 x i16>* > > %p.next_loopiv.us67 = add nsw i32 %p.loopiv48.us66, 4 > > <<<<<<<<<<<<<<<<<< > > IV > > %_p_vec_full.us71 = load <4 x i16>* %vector_ptr.us70, align...

----- Original Message ----- > From: "Paul Redmond" <paul.redmond at intel.com> > To: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> > Sent: Thursday, February 28, 2013 1:30:57 PM > Subject: [LLVMdev] parallel loop metadata simplification > > Hi, > > I've been working on clang codegen for #pragma ivdep and creating the >

Hi, I've been working on clang codegen for #pragma ivdep and creating the llvm.mem.parallel_loop_access metadata seems quite difficult. The main problem is that there are so many places where loads and stores are created and all of them need to be changed when emitting a parallel loop. Note that creating llvm.loop.parallel is not a problem. One option is to modify IRBuilder to enable