search for: sdiv

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>...

Hi llvm-dev, Looks like currently 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"? Thank...

I'm getting the following error when trying to SDIV integers greater than 128bit (on an AMD64 target). LegalizeIntegerTypes.cpp:2047: void llvm::DAGTypeLegalizer::ExpandIntRes_SDIV(llvm::SDNode*, llvm::SDValue&, llvm::SDValue&): Assertion `LC != RTLIB::UNKNOWN_LIBCALL && "Unsupported SDIV!"' failed. Stack dump: 0....

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...

...predicated integer division - it will vectorize the loop body and scalarize the predicated division instruction into a sequence of branches that guard scalar division operations. In some cases the generated code for this will not be very efficient. Speculating the divides using a non-masked vector sdiv instruction is usually not an option due to the danger of integer divide-by-zero. With the addition of these hereby proposed intrinsics the loop-vectorizer could concentrate on the vector semantics rather than how to lower them, by generating the masked intrinsics. Initially the intrinsics will be...

Hello LLVM-Dev, Attached are: · The DAG after being built · The DAG before the legalization phase The DAG illustrated performs a signed division for type i32. As can be seen, the SDIV node was converted to a series of other nodes (which includes a MULHS node). In the target lowering class of our target, the SDIV has an operation action of custom. Does anybody know where in between the SelectionDAGBuilder and the Legalization phases the SDIV node got converted? I need the SDIV no...

I've found what appears to be a bug in instcombine. Specifically, the transformation of -(X/C) to X/(-C) is invalid if C == INT_MIN. Specifically, if I have > define i32 @foo(i32 %x) #0 { > entry: > %div = sdiv i32 %x, -2147483648 > %sub = sub nsw i32 0, %div > ret i32 %sub > } then opt -instcombine will produce > define i32 @foo(i32 %x) #0 { > entry: > %sub = sdiv i32 %x, -2147483648 > ret i32 %sub > } You can observe this with the following test case: > #include <s...

...d 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')"; \ cat $^) | m4 &g...

On Sun, 21 Sep 2014, Renato Golin wrote: > On 20 September 2014 15:19, Mikulas Patocka > <mikulas at artax.karlin.mff.cuni.cz> wrote: > > The problem is this - you either compile this program with > > -mcpu=cortex-a9, then clang reports error on the sdiv instruction because > > cortex a9 doesn't have sdiv. Or - you compile the program with > > -mcpu=cortex-a15, then clang compiles it, but it uses full cortex-a15 > > instruction set and the program crashes on cortex a9 and earlier cores. > > LLVM always validates inline...

Hi, I have a simple C case as following: int test(int x, int y) { return -x / -y; } With llvm-gcc -O1, I got: define i32 @test(i32 %x, i32 %y) nounwind { entry: sub i32 0, %x ; <i32>:0 [#uses=1] sub i32 0, %y ; <i32>:1 [#uses=1] sdiv i32 %0, %1 ; <i32>:2 [#uses=1] ret i32 %2 } With llvm-gcc -O2, I got: define i32 @test(i32 %x, i32 %y) nounwind { entry: sdiv i32 %x, %y ; <i32>:0 [#uses=1] ret i32 %0 } I wonder which pass does this transform. I tried several passes, like -instcombine, -simplifycfg, -gcse -gl...

On Wed, Mar 29, 2017 at 2:15 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 3/29/2017 1:05 PM, Hongbin Zheng wrote: > >> Hi Eli, >> >> Thanks. Do you mean ideally we should extend SimplifyIndVar to do the >> sdiv->udiv replacement? >> > > I haven't really looked into it closely, but it seems to make sense. Ok. Once I extend SimplifyIndVar, e.g. the simplifyUsersOfIV function. How I can add a regression test for the extension? simplifyUsersOfIV is not a pass. Thanks Hongbin > &gt...

I was looking through the InstCombine pass, and I was wondering why signed division is not considered a valid operation to combine in the canEvaluateTruncated function. This means, given the following code: %conv = sext i16 %0 to i32 %conv1 = sext i16 %1 to i32 %div = sdiv i32 %conv, %conv1 %conv2 = trunc i32 %div to i16 * Assume %0 and %1 are registers created from simple 16-bit loads. We cannot reduce the sequence to: %div = sdiv i16 %0 %1 What is the reason for the exclusion of sdiv from the operations considered valid for execution in a truncated format. Than...

...(struct nouveau_clock *clock, int clk, u32 pll, u32 khz, +nva3_clk_info(struct nouveau_clock *clock, int clk, u32 khz, struct nva3_clock_info *info) { - struct nouveau_bios *bios = nouveau_bios(clock); struct nva3_clock_priv *priv = (void *)clock; - struct nvbios_pll limits; - u32 oclk, sclk, sdiv; - int P, N, M, diff; - int ret; + u32 oclk, sclk, sdiv, diff; - info->pll = 0; info->clk = 0; switch (khz) { @@ -188,40 +183,64 @@ nva3_clock_info(struct nouveau_clock *clock, int clk, u32 pll, u32 khz, return khz; default: sclk = read_vco(priv, clk); - sdiv = min((sclk * 2)...

...happens to zext <2 x i32> -> <2 x i64> and trunc <2 x i64> -> <2 x i32>. Any ideas to optimize these instructions? Thanks. > > %sub.ptr.sub.i6.i.i.i.i = sub <2 x i64> %sub.ptr.lhs.cast.i4.i.i.i.i, %sub.ptr.rhs.cast.i5.i.i.i.i > %sub.ptr.div.i7.i.i.i.i = sdiv <2 x i64> %sub.ptr.sub.i6.i.i.i.i, <i64 24, i64 24> > > Assembly: > vpsubq %xmm6, %xmm5, %xmm5 > vmovq %xmm5, %rax > movabsq $3074457345618258603, %rbx # imm = 0x2AAAAAAAAAAAAAAB > imulq %rbx > movq %...

...ame thing also happens to zext <2 x i32> -> <2 x i64> and trunc <2 x i64> -> <2 x i32>. Any ideas to optimize these instructions? Thanks. %sub.ptr.sub.i6.i.i.i.i = sub <2 x i64> %sub.ptr.lhs.cast.i4.i.i.i.i, %sub.ptr.rhs.cast.i5.i.i.i.i %sub.ptr.div.i7.i.i.i.i = sdiv <2 x i64> %sub.ptr.sub.i6.i.i.i.i, <i64 24, i64 24> Assembly: vpsubq %xmm6, %xmm5, %xmm5 vmovq %xmm5, %rax movabsq $3074457345618258603, %rbx # imm = 0x2AAAAAAAAAAAAAAB imulq %rbx movq %rdx, %rcx movq %rcx, %rax shrq $63, %rax shrq $...

...v at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> In the targets I know, shifts are >> cheaper than divides in both speed and size. > > From what I remember, udiv by power of 2 already gets turned into a shift in instcombine; the tricky case is sdiv by power of 2, which takes significantly more than one instruction. The generic implementation is this: > > // Splat the sign bit into the register > SDValue SGN = > DAG.getNode(ISD::SRA, DL, VT, N0, > DAG.getConstant(VT.getScalarSizeInBits() - 1,...

Hi everyone, In order to have exceptions for non-call instructions (such as sdiv, load or stores), I'm modifying codegen so that it generates a BeginLabel and an EndLabel between the "may throwing" instruction. This is what the codegen of an InvokeInst does. However, when generating native code, only BeginLabel is generated, and it is generated after the instruct...

...ntics of the safe.div intrinsic need to be useful for the Language/ISA Matrix that LLVMers care about. At canonical IR level, the intrinsic is useful by eliminating control flow merges and representing divide-by-zero and/or signed overflow in a canonical form: %res = call {i32, i1} @llvm.safe.sdiv.i32(i32 %a, i32 %b) %bit = extractvalue {i32, i1} %res, 1 br i1 %bit, label %trap, label %continue trap: call ... unreachable continue: %div = extractvalue {i32, i1} %res, 0 The original proposal fails to achieve this because the common case of Java/Go would require a check in...

Hi I have the following ARM Linux program. The program detects if the processor has division instruction, if it does, it uses it, otherwise it uses slower library call. The program works with gcc, but it doesn't work with clang. clang reports error on the sdiv instruction in the assembler. The problem is this - you either compile this program with -mcpu=cortex-a9, then clang reports error on the sdiv instruction because cortex a9 doesn't have sdiv. Or - you compile the program with -mcpu=cortex-a15, then clang compiles it, but it uses full cortex...

...t 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 function SparcDAGToDAG...