<div dir="ltr">Hey again,<div><br></div><div>I have a nagging thought that my past comments may not have enough meat to them. So...<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 8, 2013 at 12:01 PM, Cameron McInally <span dir="ltr"><<a href="mailto:cameron.mcinally@nyu.edu" target="_blank">cameron.mcinally@nyu.edu</a>></span> wrote:<div>
... </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>I was just writing Chandler about a similar implementation. With my current understanding of the problem, my constant division will end up as either a trap call or a load of an undefined value in the IR, depending on what the FE chooses to do. It's not clear to me, at least with my current knowledge of LLVM, how to recreate the actual division instruction in the target backend from that information (trap or undefined value). Hopefully there is a way. ;)</div>
</div></div></div></blockquote><div><br></div><div style>I've tried my little test case with an unmodified Clang and -fsanitize=integer-divide-by-zero. After LLVM runs the Function Integration/Inlining Pass, I end up with this IR:</div>
<div style><br></div><div>*** IR Dump Before Deduce function attributes ***</div><div>define i32 @main() #0 {</div><div>entry:</div><div>  call void @__ubsan_handle_divrem_overflow(i8* bitcast ({ { i8*, i32, i32 }, { i16, i16, [6 x i8] }* }* @2 to i8*), i64 6, i64 0) #3</div>
<div>  %call1 = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([9 x i8]* @.str, i64 0, i64 0), i32 undef) #3</div><div>  ret i32 0</div><div style>} </div><div style><br></div><div style>The problem I'm facing is how to safely convert this __ubsan_handle_divrem_overflow call back to the actual integer division in the target backend. Is it possible and I'm missing it? Any insight would be warmly welcomed.</div>
<div style><br></div><div style>On a related note, this investigation into Clang has proven insightful. My compiler's usage of LLVM differs from Clang's in many ways. So, it could be that the issues I face are peculiar to my compiler. Without delving, my input LLVM IR is heavily optimized.</div>
<div style><br></div><div style>-Cameron</div></div></div></div></div>