<div dir="ltr"><div class="gmail-gs" style="margin:0px;padding:0px 0px 20px;width:938px;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:medium"><div class="gmail-"><div id="gmail-:1by" class="gmail-ii gmail-gt" style="font-size:0.875rem;direction:ltr;margin:8px 0px 0px;padding:0px"><div id="gmail-:1ap" class="gmail-a3s gmail-aXjCH" style="overflow:hidden;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:small;line-height:1.5;font-family:Arial,Helvetica,sans-serif"><div dir="ltr"><div>I am investigating a bad codegen bug for an out-of-tree target.</div><div><br></div><div>I found out that llvm::EmitGEPOffset (file include\llvm\Analysis\Utils) will create a mul with nuw flag if the GEP isInBounds is true:</div><div><br></div><div>      Op = Builder->CreateMul(Op, ConstantInt::get(IntPtrTy, Size),<br>                              GEP->getName()+".idx", isInBounds /*NUW*/);<br></div><div><br></div><div>But what if Op is a variable that contains a negative number. In that case the nuw flag is wrong right?</div><div>Because the mul will eventually be changed to  </div><div>     %101 = shl nuw i32 %93, 2</div><div> %93 being a variable holding a negative value (clearly the 2 high bit are not 0)</div><div>This will cause a miscompile eventually.<br></div><div><br></div><div>I think llvm::EmitGEPOffset is being too aggressive in setting nuw here.</div><div>Or am I missing something?</div><div><br></div><div>(I fixed the problem locally by calling EmitGEPOffset with NoAssumptions = true) in InstructionCombining.cpp)</div></div><div class="gmail-yj6qo"></div><div class="gmail-adL"></div></div></div><div class="gmail-hi" style="border-bottom-left-radius:1px;border-bottom-right-radius:1px;padding:0px;width:auto;background:rgb(242,242,242);margin:0px"></div></div></div><br class="gmail-Apple-interchange-newline"></div>