search for: srem

...ARCH)/udiv.o: arch/$(KLIBCARCH)/udiv.S + +klibc/arch/$(KLIBCARCH)/udiv.S: klibc/arch/$(KLIBCARCH)/divrem.m4 @echo 'building $@ from $^' @(echo "define(NAME,\`.udiv')define(OP,\`div')define(S,\`false')"; \ cat $^) | m4 > $@ @chmod 444 $@ -arch/$(KLIBCARCH)/srem.S: arch/$(KLIBCARCH)/divrem.m4 +arch/$(KLIBCARCH)/srem.o: arch/$(KLIBCARCH)/srem.S + +klibc/arch/$(KLIBCARCH)/srem.S: klibc/arch/$(KLIBCARCH)/divrem.m4 @echo 'building $@ from $^' @(echo "define(NAME,\`.rem')define(OP,\`rem')define(S,\`true')"; \ cat $^) | m4 &g...

...the same type as its operands". udiv/sdiv Instruction: Add "rounded towards zero" after "quotient of the two operands". urem Instruction: Remove "regardless of whether the arguments are unsigned or not" because it doesn't make sense. Using urem instead of srem asserts that the arguments are unsigned. urem/srem Instruction: Move remainder/modulo discussion from srem to urem since many readers will read the document from top to bottom. In any case, both instructions should state "result has the same sign as the dividend". frem Instruction: Th...

On 04/25/2014 10:12 AM, Eric Christopher wrote: > Hi Andrew, > > Replying in both places because this mail is a pretty good summary of > issues and so it's worth replying to... my apologies for continuing in > both places. Responding to LLVMDev - I for one had missed this part of the thread. > >> The only language aspect under discussion is integer division. Every

...%DoubleVar2 br label %Brancher Exit: ; preds = %Brancher7, %Brancher4, %Brancher %2 = load double* %DoubleVar ; <double> [#uses=1] ret double %2 Body: ; preds = %Brancher %3 = srem i64 30, %1 ; <i64> [#uses=1] %4 = getelementptr inbounds i8* %0, i64 %3 ; <i8*> [#uses=1] %5 = load i8* %4 ; <i8> [#uses=1] %PeekResult = uitofp i8 %5 to double ; <double> [#uses=0] %6 = load d...

...an buy that. We're picking NaN for the value of the undef operand since the result will always be a NaN. So a few lines below this, we have something similar for integer operations: case ISD::ADD: case ISD::SUB: case ISD::UDIV: case ISD::SDIV: case ISD::UREM: case ISD::SREM: return getUNDEF(VT); // fold op(arg1, undef) -> undef What's the reasoning behind folding to undef here? Would that fall into the same "any value can't produce some value" bin?

...ntrinsics 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) = safe.srem(min<T>, -1) = {min<T>, 1} In other cases: safe.op(x,y) = {x op y, 0}, where op is sdiv, udiv, srem, or urem The use of these intrinsics would be quite the same as it was for arith.with.overflow intrinsics. For instance: %res = call {i32, i1} @llvm.safe.sdiv.i32(i32 %a, i32 %b)...

...change the data type of A, B & C to the integer type then it generates the right code, where div is predicated based on the mask, and scalar div gets generated for each lane. This seems like a problem in predicate instruction detection part of LV, currently it considers only UDiv, SDiv, URem, SRem. bool LoopVectorizationCostModel::isScalarWithPredication(Instruction *I, unsigned VF) { if (!Legal->blockNeedsPredication(I->getParent())) return false; switch(I->getOpcode()) { default: break; case Instruction::UDiv: <- Floating point operations not considered i.e FD...

...P_ROUND: that rounds to nearest, this rounds to zero. > setOperationAction(ISD::FP_ROUND_INREG, MVT::ppcf128, Custom); > > - // PowerPC has no intrinsics for these particular operations > - setOperationAction(ISD::MEMBARRIER, MVT::Other, Expand); > - > // PowerPC has no SREM/UREM instructions > setOperationAction(ISD::SREM, MVT::i32, Expand); > setOperationAction(ISD::UREM, MVT::i32, Expand); > Index: lib/Target/PowerPC/PPCInstrFormats.td > =================================================================== > --- lib/Target/PowerPC/PPCInstrFormats....

...@@ -78,9 +78,6 @@ // from FP_ROUND: that rounds to nearest, this rounds to zero. setOperationAction(ISD::FP_ROUND_INREG, MVT::ppcf128, Custom); - // PowerPC has no intrinsics for these particular operations - setOperationAction(ISD::MEMBARRIER, MVT::Other, Expand); - // PowerPC has no SREM/UREM instructions setOperationAction(ISD::SREM, MVT::i32, Expand); setOperationAction(ISD::UREM, MVT::i32, Expand); -------------- next part -------------- A non-text attachment was scrubbed... Name: test.bc Type: application/octet-stream Size: 236 bytes Desc: not available URL: <http://li...

...p i32 %lsr.iv to double ; <double> [#uses=1] %r_fmul = fmul double %fp, 3.151900e+00 ; <double> [#uses=1] %r_fadd = fadd double %r_fmul, 2.800000e+00 ; <double> [#uses=1] %r_fmul5 = fmul double %r_fadd, 5.320000e+00 ; <double> [#uses=2] %r_srem = srem i32 %lsr.iv, 17 ; <i32> [#uses=1] %r_icmpeq = icmp eq i32 %r_srem, 1 ; <i1> [#uses=1] br i1 %r_icmpeq, label %then, label %loop.endif_crit_edge loop.endif_crit_edge: ; preds = %loop br label %endif then:...

...ructions 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 instructions mul, udiv, urem, sdiv, srem that are know to be not supported by target's type legalization with a call to a function that implements given arithmetic operation. 3. The pass also injects these functions to the module with a weak linkage. 4. The pass requires a function generator (interface implementation) f...

...@@ -78,9 +78,6 @@ // from FP_ROUND: that rounds to nearest, this rounds to zero. setOperationAction(ISD::FP_ROUND_INREG, MVT::ppcf128, Custom); - // PowerPC has no intrinsics for these particular operations - setOperationAction(ISD::MEMBARRIER, MVT::Other, Expand); - // PowerPC has no SREM/UREM instructions setOperationAction(ISD::SREM, MVT::i32, Expand); setOperationAction(ISD::UREM, MVT::i32, Expand); Index: lib/Target/PowerPC/PPCInstrFormats.td =================================================================== --- lib/Target/PowerPC/PPCInstrFormats.td (revision 54985) +++ l...

%tmp63 = call %struct.TypHeader* (...)* bitcast (%struct.TypHeader* (%struct.TypHeader*, i64, i64)* @Cyclotomic to %struct.TypHeader* (...)*)(%struct.TypHeader* %tmp62, i64 %tmp24, i32 1) nounwind, !dbg !907 ; <%struct.TypHeader*> [#uses=1] the 3rd parameter is now used in an srem statement. How do we know what value is used? Does this use decide whether the value is sign extended or zero extended? Arushi On Tue, Apr 5, 2011 at 1:35 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Arushi, > > > For a call like this, > > > > %tmp6 = call i32...

...ble ; <double> [#uses=1] > %r_fmul = fmul double %fp, 3.151900e+00 ; <double> [#uses=1] > %r_fadd = fadd double %r_fmul, 2.800000e+00 ; <double> [#uses=1] > %r_fmul5 = fmul double %r_fadd, 5.320000e+00 ; <double> [#uses=2] > %r_srem = srem i32 %lsr.iv, 17 ; <i32> [#uses=1] > %r_icmpeq = icmp eq i32 %r_srem, 1 ; <i1> [#uses=1] > br i1 %r_icmpeq, label %then, label %loop.endif_crit_edge > > loop.endif_crit_edge: ; preds = %loop > br label...

...10 = load i32* %9 %11 = icmp sgt i32 %10, %v6_int_34 br i1 %11, label %cond_4, label %cond_4_else1 cond_4_else1: ; preds = %cond_4_else %a3 = load i32** @a %v43 = load i32* %v4 %12 = getelementptr i32* %a3, i32 %v43 %13 = load i32* %12 %v5_int_42 = srem i32 %v2_int_.0, %13 %14 = icmp eq i32 %v5_int_42, 0 br i1 %14, label %cond_4_else2, label %cond_4 ************************************************************************ (I change the variable's name a little bit for the first four instructions in each BB because the name of variables in...

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 On 11 Mar 2010, at 18:27, Russell Wallace wrote: > Does LLVM support any target platforms on which the natural integer > size/pointer size is smal...

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:

Does LLVM support any target platforms on which the natural integer size/pointer size is smaller than 32 bits? For example, I noticed mention of PIC16, is that such a platform? If so, does the usual rule about the largest supported integer being the size of two pointers still apply? So that on that platform you can't use 64-bit integers, but you can use 32-bit integers?

...call %struct.TypHeader* (...)* bitcast (%struct.TypHeader* > (%struct.TypHeader*, i64, i64)* @Cyclotomic to %struct.TypHeader* > (...)*)(%struct.TypHeader* %tmp62, i64 %tmp24, i32 1) nounwind, !dbg !907 ; > <%struct.TypHeader*> [#uses=1] > > the 3rd parameter is now used in an srem statement. How do we know what value is > used? Does this use decide whether the value is sign extended or zero extended? inside the called function the 3rd value will contain rubbish. That's because the function takes an i64 parameter but via the bitcast you pretend it takes an i32 parame...

...s to nearest, this rounds to zero. >> setOperationAction(ISD::FP_ROUND_INREG, MVT::ppcf128, Custom); >> >> - // PowerPC has no intrinsics for these particular operations >> - setOperationAction(ISD::MEMBARRIER, MVT::Other, Expand); >> - >> // PowerPC has no SREM/UREM instructions >> setOperationAction(ISD::SREM, MVT::i32, Expand); >> setOperationAction(ISD::UREM, MVT::i32, Expand); >> Index: lib/Target/PowerPC/PPCInstrFormats.td >> =================================================================== >> --- lib/Target/PowerP...