Displaying 20 results from an estimated 171 matches for "udiv".
Did you mean:
div
2017 Jul 31
4
unsigned operations with negative numbers
Hello,
I want to know, if I can always assume that when I do unsigned operations
like
udiv, urem
I will get the both operands converted to unsigned values? with under
optimized version of code I sometimes receive these lines:
unsigned a = 123;
int b = -2;
int c = a / b;
-> %1 = udiv i32 123, -2
and get the result 0. Will it always be zero? or is it undefined?...
2017 Nov 29
3
RFC: Adding 'no-overflow' keyword to 'sdiv'\'udiv' instructions
Introduction:
We would like to add new keyword to 'sdiv'\'udiv' instructions i.e. 'no-overflow'.
This is the updated solution devised in the discussion: http://lists.llvm.org/pipermail/llvm-dev/2017-October/118257.html
The proposed keywords:
"nof" stands for 'no-overflow'
Syntax:
<result> = sdiv nof <...
2011 Dec 17
1
[LLVMdev] nsw is still logically inconsistent
...afe to
> speculate if the index is known to be bounded. isDereferenceablePointer
> currently doesn't know how to do this, but it'll probably get
> smarter some day.
So, looking at just this example, it looks like semantics we assign to
poison values have to do one of
*) Avoid the udiv being moved, since a valid removal of nsw would create
a program that is now exposed to undefined behavior.
*) Say that use of poison values only produces other poison values, not
undefined behavior.
The second option would give us a lot of liberty to move instruction
around, but is a major chang...
2011 Dec 12
5
[LLVMdev] nsw is still logically inconsistent
...plicit pass dependency,
which is against the rules.
Ok, consider this LLVM IR code fragment:
br i1 %overflow_check, label %no_overflow, label %end
no_overflow:
%t0 = add nsw i32 %a, %b
%t1 = sext i32 %t0 to i64
%t2 = ashr i64 %t1, 31
%t3 = add i64 %t2, 1
%t5 = icmp ult %t3, 2
%t6 = udiv i1 1, %t5
Assume label %no_overflow has no other predecessors. And assume
adding %a and %b can sometimes produce overflow, but only when
%overflow_check is false.
This code has no undefined behavior. It's a bit subtle, but in
particular, note that it's not possible for the udiv to divide...
2017 Jun 02
5
RFC: Killing undef and spreading poison
Sanjoy,
My answer is that step 3, commuting the multiply with the sign-extends, is invalid,
As this is what causes the `udiv` to fault. I think it is invalid with or without the “freeze”,
why do you think step 3, the commute, without the “freeze" is valid ?
Also, do you think you can come up with an example that does not depend on signed
overflow being “undefined” ?
Peter Lawrence.
>
>
>>
&...
2006 Apr 18
1
[patch] sparc build fix
...s been since long in the Debian and Ubuntu klibc.
diff --git a/klibc/arch/sparc/Makefile.inc b/klibc/arch/sparc/Makefile.inc
index 41c23c5..d77030d 100644
--- a/klibc/arch/sparc/Makefile.inc
+++ b/klibc/arch/sparc/Makefile.inc
@@ -23,25 +23,33 @@ KLIBCARCHOBJS = \
libgcc/__umoddi3.o \
libgcc/__udivmoddi4.o
-arch/$(KLIBCARCH)/sdiv.S: arch/$(KLIBCARCH)/divrem.m4
+arch/$(KLIBCARCH)/sdiv.o: arch/$(KLIBCARCH)/sdiv.S
+
+klibc/arch/$(KLIBCARCH)/sdiv.S: klibc/arch/$(KLIBCARCH)/divrem.m4
@echo 'building $@ from $^'
@(echo "define(NAME,\`.div')define(OP,\`div')define(S,\`true...
2016 Nov 11
2
RFC: Killing undef and spreading poison
...inced that you
> lose optimization power except in code that actually exhibits undefined
> behavior.
I'm not sure I understood your concern fully, but you could have cases like:
for (...) {
if (condition){
i32 prod = x *nsw y
i64 prod.sext = sext prod to i64
i64 t = K `udiv` (-1 + (sum.prod >> 32))
use(t)
}
}
The C program this came from is well defined in two cases (that are
relevant here):
1. condition is false
2. condition is true and x * y does not sign overflow
We'd like to LICM the entire expression tree out of control flow in a
way th...
2011 Dec 14
2
[LLVMdev] nsw is still logically inconsistent
...orm a speculation transformation, hoisting all of the
>> code above the %overflow_check branch:
>>
>> %t0 = add nsw i32 %a, %b
>> %t1 = sext i32 %t0 to i64
>> %t2 = ashr i64 %t1, 31
>> %t3 = add i64 %t2, 1
>> %t5 = icmp ult %t3, 2
>> %t6 = udiv i1 1, %t5
>> br i1 %overflow_check, label %no_overflow, label %end
>>
>> no_overflow:
>>
>> Was this valid?
>>
>> If nsw overflow is immediate undefined behavior, this transformation
>> would break the program, because the overflow is no longer guar...
2010 Jan 01
2
[LLVMdev] Assembly Printer
...& 1023)", it prints "sra".
Does this make sense or am I just overlooking something?
The second question is about pattern matching of instructions.
I found that some of the target instructions do not have corresponding
patterns to match.
For example, in SparcInstrInfo.td, "udiv" and "sdiv" don't seem to have any
patterns specified.
defm UDIV : F3_12np<"udiv", 0b001110>;
defm SDIV : F3_12np<"sdiv", 0b001111>;
Is this because these instructions are handled differently from other
instructions in SparcISelDAGToDAG.cpp?
In f...
2011 Dec 15
0
[LLVMdev] nsw is still logically inconsistent
...hoisting all of the
>>> code above the %overflow_check branch:
>>>
>>> %t0 = add nsw i32 %a, %b
>>> %t1 = sext i32 %t0 to i64
>>> %t2 = ashr i64 %t1, 31
>>> %t3 = add i64 %t2, 1
>>> %t5 = icmp ult %t3, 2
>>> %t6 = udiv i1 1, %t5
>>> br i1 %overflow_check, label %no_overflow, label %end
>>>
>>> no_overflow:
>>>
>>> Was this valid?
>>>
>>> If nsw overflow is immediate undefined behavior, this transformation
>>> would break the program, bec...
2015 Feb 17
5
[LLVMdev] why llvm does not have uadd, iadd node
Hi guys,
I just noticed that the LLVM has some node for signed/unsigned type( like udiv, sdiv), but why the ADD, SUB do not have the counter part sadd, uadd?
best
kevin
2017 Mar 29
2
sdiv in array subscript
...ScalarEvolution will give up if there is a sdiv in
array subscript, e.g.
int i;
A[i * 64 / 2]
in this case ScalarEvolution will just return an unknown for (i * 64 / 2).
For this case, InstCombine will do the jobs, but in general, is there a
pass to deal with the sdiv here? like replace sdiv by udiv based on the
range of "i"?
Thanks
Hongbin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170329/1796952a/attachment.html>
2017 Mar 29
2
sdiv in array subscript
Hi Eli,
Thanks. Do you mean ideally we should extend SimplifyIndVar to do the
sdiv->udiv replacement?
Thanks
Hongbin
On Wed, Mar 29, 2017 at 10:59 AM, Friedman, Eli <efriedma at codeaurora.org>
wrote:
> On 3/29/2017 10:35 AM, Hongbin Zheng via llvm-dev wrote:
>
>> Hi llvm-dev,
>>
>> Looks like currently ScalarEvolution will give up if there is a sdiv in...
2018 May 23
0
RFC: should CVP always narrow the width of lshr?
Hi.
In https://reviews.llvm.org/D46760,
Bixia Zheng notes that given the pattern like [1]
%za = zext i32 %a to i64
%udiv = udiv i64 %za, <C>
%urem = urem i64 %za, <C>
%uadd = add i64 %udiv, %urem
ret i64 %uadd
the CVP will reduce the width of udiv/urem,
without considerations for the new instructions,
or whether the new width is legal for the target.
That was implemented in https://reviews.llvm.org...
2017 Jul 03
2
trunc nsw/nuw?
...w keyword is
present, the result value of the trunc is a poison value if the truncated
high order bits are not all equal to the non-truncated bit of the highest
order.
This allow to cancel out:
- sext with trunc nsw
- zext with trunc nuw
And probably to commute with add/sub/mul/lshr/ashr/shl/urem/udiv/udiv (with
the correct flags).
[1]: http://llvm.org/docs/LangRef.html#trunc-to-instruction
--
*Alexandre Isoard*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170703/5fb31f9a/attachment.html>
2018 Dec 14
2
Dealing with information loss for widened integer operations at ISel time
...orms
> if you don't need the sign extension. Unless MULW has lower latency than
> MUL on some CPU?
It only matters when it allows you to avoid an unnecessary sext/zext
of the input operands. Consider the following input:
define i32 @aext_divuw_aext_aext(i32 %a, i32 %b) nounwind {
%1 = udiv i32 %a, %b
ret i32 %1
}
This pattern won't match:
def : Pat<(sext_inreg (udiv (zexti32 GPR:$rs1), (zexti32 GPR:$rs2)), i32),
(DIVUW GPR:$rs1, GPR:$rs2)>;
This pattern would match but is incorrect in the general case (e.g. if
rs1 is 0xffffffff and rs2 is 0x1, the result will...
2011 Dec 14
0
[LLVMdev] nsw is still logically inconsistent
...> Next, we perform a promotion transformation, converting the add nsw
> from i32 to i64:
>
> %s0 = sext i32 %a to i64
> %s1 = sext i32 %b to i64
> %t0 = add nsw i64 %s0, %s1
> %t2 = ashr i64 %t0, 31
> %t3 = add i64 %t2, 1
> %t5 = icmp ult %t3, 2
> %t6 = udiv i1 1, %t5
> br i1 %overflow_check, label %no_overflow, label %end
>
> no_overflow:
>
> Was this valid?
>
> Any time the new i64 add would produce a different value than the
> original sext would have, it would be a case where the 32-bit add
> had an overflow. The nsw sa...
2010 Jan 03
0
[LLVMdev] Assembly Printer
...overlooked. Perhaps tblgen didn't get rerun or something didn't get relinked.
> The second question is about pattern matching of instructions.
> I found that some of the target instructions do not have corresponding patterns to match.
> For example, in SparcInstrInfo.td, "udiv" and "sdiv" don't seem to have any patterns specified.
>
> defm UDIV : F3_12np<"udiv", 0b001110>;
> defm SDIV : F3_12np<"sdiv", 0b001111>;
>
> Is this because these instructions are handled differently from other instructions in...
2011 Dec 14
0
[LLVMdev] nsw is still logically inconsistent
> We first perform a speculation transformation, hoisting all of the
> code above the %overflow_check branch:
>
> %t0 = add nsw i32 %a, %b
> %t1 = sext i32 %t0 to i64
> %t2 = ashr i64 %t1, 31
> %t3 = add i64 %t2, 1
> %t5 = icmp ult %t3, 2
> %t6 = udiv i1 1, %t5
> br i1 %overflow_check, label %no_overflow, label %end
>
> no_overflow:
>
> Was this valid?
>
> If nsw overflow is immediate undefined behavior, this transformation
> would break the program, because the overflow is no longer guarded
> by %overflow_check....
2012 Jun 28
0
[LLVMdev] 8-bit DIV IR irregularities
...e is no way to write an 8-bit divide in C; it's a 32-bit divide
where each operand happens to be a sign extension from an 8-bit type.
> If someone knows where the 8-bit DIV is being handled in the IR I could look into this change?
For your div8 testcase, instcombine transforms from a "udiv i32" to a
"udiv i8". instcombine isn't allowed to do that for "sdiv i32"
because it potentially introduces undefined behavior.
-Eli