similar to: 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

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

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 <ty> <op1>,

add object rules so that the division, remainder and friends get really build on sparc, patch from Fabio M. Di Nitto <fabbione@ubuntu.com>. reworked to apply on latest git tree. Signed-off-by: maximilian attems <maks@sternwelten.at> --- Has been since long in the Debian and Ubuntu klibc. diff --git a/klibc/arch/sparc/Makefile.inc b/klibc/arch/sparc/Makefile.inc index

I am trying to understand how LLVM does code generation and I have a couple of questions. I am using LLVM 2.6. First, if I want to change the name of an instruction, all I need to do is to modify the XXXInstrInfo.td, right? Using Sparc as an example, if I wanted to output "mysra" instead of "sra", in SparcInstrInfo.td, I would write, defm SRA : F3_12<"mysra",

Hi, I'm using pass ScalarEvolution to analyze the loop trip count on my application. And I found a possible bug in the code, that is in function SCEVAddRecExpr::getNumIterationsInRange(), Line 2905: 2904 // The exit value should be (End+A)/A. 2905 APInt ExitVal = (End + A).udiv(A); 2906 ConstantInt *ExitValue = ConstantInt::get(ExitVal); The divide should be sdiv, right?

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

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?

I understand, but this sounds like legalization. Does every architecture trigger an overflow exception, as opposed to setting a bit? Perhaps it makes more sense to do this in the backends that trigger an overflow exception? I'm working on a modification for DIV right now in the x86 backend for Intel Atom that will improve performance, however because the *actual* operation has been replaced

Hi LLVM, This is my idea I had some time ago, when I realized that LLVM did not support legalization of some arithmetic instructions like mul i256. I have implemented very simple and limited version of that in my project. Is it something LLVM users would appreciate? 1. The pass transforms IR and is meant to be run before CodeGen (after IR optimizations). 2. The pass replaces

Hi, in section B.29. (Write State Register Instructions) of 'The SPARC Architecture Manual Version 8' it is said that the "The write state register instructions are delayed-write instructions." The Y-register is a state-register. Furthermore in the B.29-secion there is a programming note saying: MULScc, RDY, SDIV, SDIVcc, UDIV, and UDIVcc implicitly read the Y register.

On Fri, Feb 7, 2020 at 12:29 PM Nuno Lopes <nunoplopes at sapo.pt> wrote: > > It's not correct (output of Alive2): > > define half @fn(half %a) { > %b = fadd half %a, undef > ret half %b > } > => > define half @fn(half %a) { > ret half undef > } > Transformation doesn't verify! > ERROR: Value mismatch > > Example: > half %a

Hi, Consider the following test case: int foo(float *A, float *B, float *C, int len, int VSMALL) { for (int i = 0; i < len; i++) if (C[i] > VSMALL) A[i] = B[i] / C[i]; } In this test the div operation is conditional but llvm is generating unconditional div for this case: vector.body: ; preds = %vector.body, %vector.ph %index = phi i64 [

Hi, I’d like to propose to extend LLVM IR intrinsics set, adding new ones for safe-division. There are intrinsics for detecting overflow errors, like sadd.with.overflow, and the intrinsics I’m proposing will augment this set. The new intrinsics will return a structure with two elements according to the following rules: safe.[us]div(x,0) = safe.[us]rem(x,0) = {0, 1} safe.sdiv(min<T>, -1) =

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

On Wed, Jun 27, 2012 at 5:22 PM, Nowicki, Tyler <tyler.nowicki at intel.com> wrote: > I understand, but this sounds like legalization. Does every architecture trigger an overflow exception, as opposed to setting a bit? Perhaps it makes more sense to do this in the backends that trigger an overflow exception? The IR instruction has undefined behavior on overflow. This has nothing to do

> On 24.07.2015, at 08:06, zhi chen <zchenhn at gmail.com> wrote: > > It seems that that it's hard to vectorize int64 in LLVM. For example, LLVM 3.4 generates very complicated code for the following IR. I am running on a Haswell processor. Is it because there is no alternative AVX/2 instructions for int64? The same thing also happens to zext <2 x i32> -> <2 x

It seems that that it's hard to vectorize int64 in LLVM. For example, LLVM 3.4 generates very complicated code for the following IR. I am running on a Haswell processor. Is it because there is no alternative AVX/2 instructions for int64? The same thing also happens to zext <2 x i32> -> <2 x i64> and trunc <2 x i64> -> <2 x i32>. Any ideas to optimize these

Hello LLVM, A recent commit creates the isIntDivCheap() target query. http://reviews.llvm.org/D12082 The current approach has a couple shortcomings. First, when targets decide divide is cheap, the DAGCombiner ignores obvious power-of-2 optimizations. In the targets I know, shifts are cheaper than divides in both speed and size. The target cannot see the value in the isIntDivCheap() call, so

On April 25, 2014 at 9:52:35 AM, Eric Christopher (echristo at gmail.com) wrote: Hi Michael, > I’d like to propose to extend LLVM IR intrinsics set, adding new ones for > safe-division. There are intrinsics for detecting overflow errors, like > sadd.with.overflow, and the intrinsics I’m proposing will augment this set. > > The new intrinsics will return a structure with two