[LLVMdev] Apparent indeterminism in PreVerifier

Sergei Larin slarin at codeaurora.org
Tue Jan 29 08:48:21 PST 2013


Nadav,

  As I peel this onion, it looks like you might know something about
InnerLoopVectorizer::addRuntimeCheck.
What does it do, and can it be causing the below described issue? Could
resuming somehow (indeterministically) switch the order of PHIs in the
original code?

Thanks a lot.

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 Sergei Larin
> Sent: Tuesday, January 29, 2013 10:31 AM
> To: llvmdev at cs.uiuc.edu
> Subject: [LLVMdev] Apparent indeterminism in PreVerifier
> 
> 
> Hello everybody,
> 
> 
>   I have a case of suspected indeterminism and I would like to verify
> that it is not a known issue before I dig deep into it.
> It seems to happen during PreVerifier pass ("Preliminary module
> verification"). The little I understand/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: Found a vectorizable loop (8) in core_state.i
> LV: Adding RT check for range:  %add.ptr4.us72.phi = phi i8* [
> %add.ptr4.us72.gep, %for.body.lr.ph.us81 ], [ %add.ptr4.us72.inc,
> %for.body.us68 ]
> LV: Adding RT check for range:  %arrayidx.us70.phi = phi i8* [
> %buf.0.ph,
> %for.body.lr.ph.us81 ], [ %arrayidx.us70.inc, %for.body.us68 ]
> 
> 
> 
> Then there are two possible outcomes triggered by a code change in
> completely unrelated portion of the code and rebuild:
> 
> *** IR Dump After Preliminary module verification ***
> 
> First version:
> 
> for.body.us68:                                    ; preds = %scalar.ph,
> %for.body.us68
>   %arrayidx.us70.phi = phi i8* [ %resume.val200, %scalar.ph ], [
> %arrayidx.us70.inc, %for.body.us68 ]
>   %add.ptr4.us72.phi = phi i8* [ %resume.val, %scalar.ph ], [
> %add.ptr4.us72.inc, %for.body.us68 ]
> 
> Second version:
> 
> for.body.us68:                                    ; preds = %scalar.ph,
> %for.body.us68
>   %arrayidx.us70.phi = phi i8* [ %resume.val, %scalar.ph ], [
> %arrayidx.us70.inc, %for.body.us68 ]
>   %add.ptr4.us72.phi = phi i8* [ %resume.val200, %scalar.ph ], [
> %add.ptr4.us72.inc, %for.body.us68 ]
> 
> This difference snowballs there after causing different instruction
> order and ultimately a different code.
> 
> If it rings the bell for anyone, or it is a known issue, please let me
> know.
> 
> Thanks.
> 
> Sergei
> 
> 
> ---
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list