similar to: [LLVMdev] Smaller than 32-bit?

Hi Russell- The PIC16 is an 8-bit target, and the msp430 is a 16-bit target. The rules about the largest supported integer no longer apply as much- for most operations, codegen can now handle arbitrary precision (exceptions: mul, udiv, urem, sdiv, srem). For those five, library calls should be emitted for big integers - best way to check if they're supported is to just try them :) Alastair

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

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?

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 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, 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) =

Here are some clarifications for the reference manual. Please verify that my assumptions are correct. Shall I post a patch? Floating-point Constants: Add "The assembler requires the exact decimal value of a floating-point constant. For example, the assembler accepts '1.25' but rejects '1.3' because '1.3' is a repeating decimal in binary." Binary

Hi, I am working with SCEVs, I see the unsigned division of SCEVs, it is not immediately clear to me why the signed division of SCEV expressions is not supported by SE? I would appreciate if some could clarify or point me to some links. -- Regards, DTharun -------------- next part -------------- An HTML attachment was scrubbed... URL:

How can I check if a particular Integer Type is signed/unsigned? Arushi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100916/baea061d/attachment.html>

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

I came across this comment in SelectionDAG.cpp: case ISD::FADD: case ISD::FSUB: case ISD::FMUL: case ISD::FDIV: case ISD::FREM: // If both operands are undef, the result is undef. If 1 operand is undef, // the result is NaN. This should match the behavior of the IR optimizer. That isn't intuitive to me. I would have expected a binary FP operation with one undef operand to

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

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"? Thanks Hongbin

Dear all, Hi! I noticed an interesting situation when using getUnsignedRange and getSignedRange of SCEV for URem instruction. Here is an example with 2 IR instructions: %rem.lhs.trunc = trunc i32 %i15.082 to i8 --> getUnsignedRange --> [1,50) %rem81 = urem i8 %rem.lhs.trunc, 3 --> getUnsignedRange --> [-47,50) The problems are: 1) From my

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

Alex, ping? There was a thread about moving Risc-V out of experimental but I think it didn't go anywhere? Separately, do the listed patches sound okay for merging? Thanks, Hans On Fri, Jan 25, 2019 at 4:40 PM Bruce Hoult <brucehoult at sifive.com> wrote: > > In https://llvm.org/svn/llvm-project/llvm/branches/release_80 I find > that RISCV is still in

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",

Per subject, this patch adding an additional pass to handle vector operations; the idea is that this allows removing the code from LegalizeDAG that handles illegal types, which should be a significant simplification. There are still some issues with this patch, but does the approach look sane? -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp

In -help output, -help - Display available options (--help-hidden for more) Both single and double - option markers are accepted, which is good. It would probably be better to refer to options consistently using the single marker in all cases. =linearscan - linear scan register allocator =pbqp - PBQP