search for: urem

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 perspective, the get...

...BCARCH)/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 > $@ @chmod 444 $@ -arch/$(KLIBCARCH)/urem.S: arch/$(KLIBCARCH)/divrem.m4 +arch/$(KLIBCARCH)/urem.S: klibc/arch/$(KLIBCARCH)/urem.S + +klibc/arch/$(KLIBCARCH)/urem.S: klibc/arch/$(KLIBCARCH)/divrem.m4 @echo 'building $@ from $^' @(echo "define(NAME,\`.urem')define(OP,\`rem')define(S,\`false')"; \ cat $^)...

Good that you bring this up. I still have no solution to this vectorization problem. However, I can rewrite the code and insert a second loop which eliminates the 'urem' and 'div' instructions in the index calculations. In this case, the inner loop's trip count would be equal to the SIMD length and the loop vectorizer ignores the loop. Unrolling the loop and SLP is not an option, since the loop body can get lengthy. What would be a quicker to i...

...perations: Replace "The result value of a binary operator is not necessarily the same type as its operands" with "The result value has 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 t...

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

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/D44102 As Sanjay Patel notes in...

Sent from my iPhone > On Nov 5, 2013, at 7:39 PM, Frank Winter <fwinter at jlab.org> wrote: > > Good that you bring this up. I still have no solution to this vectorization problem. > > However, I can rewrite the code and insert a second loop which eliminates the 'urem' and 'div' instructions in the index calculations. In this case, the inner loop's trip count would be equal to the SIMD length and the loop vectorizer ignores the loop. Unrolling the loop and SLP is not an option, since the loop body can get lengthy. > > What would be a quick...

...ter <fwinter at jlab.org > <mailto:fwinter at jlab.org>> wrote: > >> Good that you bring this up. I still have no solution to this >> vectorization problem. >> >> However, I can rewrite the code and insert a second loop which >> eliminates the 'urem' and 'div' instructions in the index >> calculations. In this case, the inner loop's trip count would be >> equal to the SIMD length and the loop vectorizer ignores the loop. >> Unrolling the loop and SLP is not an option, since the loop body can >> get l...

...c, %Matrix* %dst, i32 %len) { entry: br label %loop_i loop_i: ; preds = %loop_i_end, %entry %i = phi i32 [ 0, %entry ], [ %increment_i, %loop_i_end ] %0 = getelementptr inbounds %Matrix* %dst, i32 0, i32 2 %dst_columns = load i32* %0 *%dst_yRem = urem i32 %i, %dst_columns %dst_y = urem i32 %i, %dst_columns %1 = sub i32 %i, %dst_y %2 = add i32 %1, %dst_yRem* %3 = getelementptr inbounds %Matrix* %src, i32 0, i32 0 %4 = load i8** %3 %src_data = bitcast i8* %4 to double* %5 = getelementptr double* %src_data, i32 %2 %6 = load double*...

...be the case when I saw the original expression. Maybe we need to teach module arithmetic to SCEV? I let this thread get stale, so here’s the background again: source: const std::uint64_t ir0 = i%4 + 8*(i/4); c[ ir0 ] = a[ ir0 ] + b[ ir0 ]; before instcombine: %4 = urem i64 %i.0, 4 %5 = udiv i64 %i.0, 4 %6 = mul i64 8, %5 %7 = add i64 %4, %6 %8 = getelementptr inbounds float* %a, i64 %7 after instcombine: %2 = and i64 %i.04, 3 %3 = lshr i64 %i.04, 2 %4 = shl i64 %3, 3 %5 = or i64 %4, %2 %11 = getelementptr inbounds float* %c, i64 %5 store flo...

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

...bove shows. Ok, I can 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?

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

...ND: 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 (r...

...8,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://lists.l...

...8,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) +++ lib/Ta...

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

On 30 October 2013 18:40, Frank Winter <fwinter at jlab.org> wrote: > const std::uint64_t ir0 = (i+0)%4; // not working > I thought this would be the case when I saw the original expression. Maybe we need to teach module arithmetic to SCEV? --renato -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

Hi Josh, On 03/12/12 02:58, Josh Klontz wrote: > Hello, I'm a new LLVM user working on a C++ EDSL for image processing. I have > a function, which after applying createInstructionCombiningPass() and > createDeadCodeEliminationPass() looks like: > ... > *%dst_yRem = urem i32 %i, %dst_columns > %dst_y = urem i32 %i, %dst_columns > %1 = sub i32 %i, %dst_y > %2 = add i32 %1, %dst_yRem* ... > My question is which optimization pass(es) are needed to simplify the > instructions in bold. I've tried running the same passes again and also > t...