[llvm-dev] SCEVUDiv simplification

[Alexandre Isoard via llvm-dev]

The LLVM-IR says that udiv by zero is undefined behavior.

So, I believe if trap on divide by zero is a required behavior then it has
to be tested before in a different way.
Which would make my transformation ok?

Clang adds sanitation check before trying the udiv when compiled with
-fsanitize=undefined :

define i32 @foo(i32, i32) local_unnamed_addr #0 {
%3 = icmp eq i32 %1, 0, !nosanitize !2
br i1 %3, label %4, label %7, !prof !3, !nosanitize !2

%5 = zext i32 %0 to i64, !nosanitize !2
%6 = zext i32 %1 to i64, !nosanitize !2
tail call void @__ubsan_handle_divrem_overflow(i8* bitcast ({ { [63 x i8]*,
i32, i32 }, { i16, i16, [15 x i8] }* }* @1 to i8*), i64 %5, i64 %6) #2, !
nosanitize !2
br label %7, !nosanitize !2

%8 = udiv i32 %0, %1
ret i32 %8
}


On Thu, Aug 2, 2018 at 6:22 PM Hongbin Zheng <etherzhhb at gmail.com> wrote:

> Maybe because when n is 0, it trap? And you simplification get rid of the
> trap?
>
> On Thu, Aug 2, 2018 at 10:03 AM Alexandre Isoard via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hello,
>>
>> I noticed that our SCEVUDiv does not simplify anything when the RHS is
>> not a constant.
>> Is that because there is a potential issue with division by zero being
>> simplified?
>>
>> For instance, would it be okay to simplify:
>>
>> ((%i * %n)<nuw> /u %n)
>>
>> into: %i
>>
>> The way I see it, if %n is 0, then that division is undefined and we can
>> "define it", at will, as being %i.
>>
>> Would that make sense in SCEV world?
>>
>>
>> --
>> *Alexandre Isoard*
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>

-- 
*Alexandre Isoard*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180802/b7ffaa53/attachment.html>