similar to: SCEVUDiv simplification

On Wed, Jul 5, 2017 at 3:59 PM, Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 07/04/2017 01:41 AM, Dr.-Ing. Christoph Cullmann via llvm-dev wrote: > >> Hi, >> >> Hi Alexandre, >>> >>> LLVM currently doesn't have trunc nsw/nuw, no. >>> Which frontend would emit such instructions? Any application in mind?

On 07/05/2017 03:10 PM, Alexandre Isoard wrote: > Ah, ok. I read it wrong. In *neither* case it is UB. > > Hum, can an implementation define it as UB? :-) Nope :-) The only case I've thought of where we could add these for C++ would be on conversions to (most) enums (because they used signed underlying types and the out-of-bounds mapping won't generally be one of the allowed

Hello, >From [1], trunc does not seems to have a nsw/nuw attribute. Is it possible to have that? Or do we have that and it is not up-to-date? The definition would be: If the nuw keyword is present, the result value of the trunc is a poison value if the truncated high order bits are non-zero. If the nsw keyword is present, the result value of the trunc is a poison value if the truncated high

Hi, > Hi Alexandre, > > LLVM currently doesn't have trunc nsw/nuw, no. > Which frontend would emit such instructions? Any application in mind? > Just asking because if no frontend could emit those, then the motivation to > add nsw/nuw support to trunc would be very low I guess. I think the clang frontend could use that to allow better static analysis of integer overflows on

Note that there is a slight difficulty due to the fact that we "sink" the trunc: (zext i16 {0,+,1}<%bb> to i32) + (65536 * ({0,+,1}<nuw><%bb> /u 65536) Here the recurrence lost it's <nuw> and got reduced to a i16 (on the left), but not on the right. But we can prove: - that (zext i16 {0,+,1}<%bb> to i32) has the same 16 LSB than (i32

According to 6.3.1.3/3 of the C standard (I didn't check C++): "3 Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised." I *think* that means that IF a signal is raised then the signal raised could be one that you can't guarantee to be able to return from

Hi, Even if there are no ways in which a *frontend* can produce nsw truncs, it may still be useful to have if optimization passes can usefully attach nsw to truncates (after proving the truncates don't "overflow"). For instance in %a = ashr i64 %v, i32 33 %t = trunc %a to i32 the trunc can be marked nsw. However, the burden of proof here is to show that we can do some useful

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?

Ok. To go back to the original issue, would it be meaningful to add a SCEVUMax(0, BTC) on the final BTC computed by SCEV? So that it does not use "negative values"? On Wed, Aug 15, 2018 at 2:40 PM Friedman, Eli <efriedma at codeaurora.org> wrote: > On 8/15/2018 2:27 PM, Alexandre Isoard wrote: > > I'm not sure I understand the poison/undef/UB distinctions. >

Hello, I assumed SCEV purpose was to be a normal form, but then I wondered which one of those is the normal form: (zext i16 (trunc i32 %a to i16) to i32) vs (-((%a /u 65536) *u 65536) + %a) The first one is nice for interval analysis, and known bit analysis. The second one is nice when plugged into gep of 2d arrays. -- *Alexandre Isoard* -------------- next part -------------- An HTML

I'm not sure I understand the poison/undef/UB distinctions. But on this example: define i32 @func(i1 zeroext %b, i32 %x, i32 %y) { > entry: > %adds = add nsw i32 %x, %y > %addu = add nuw i32 %x, %y > %cond = select i1 %b, i32 %adds, i32 %addu > ret i32 %cond > } It is important to not propagate the nsw/nuw between the two SCEV expressions (which unification would

Is that why we do not deduce +<nsw> from "add nsw" either? Is that an intrinsic limitation of creating a context-invariant expressions from a Value* or is that a limitation of our implementation (our unification not considering the nsw flags)? On Wed, Aug 15, 2018 at 12:39 PM Friedman, Eli <efriedma at codeaurora.org> wrote: > On 8/15/2018 12:21 PM, Alexandre Isoard via

Hello, If I run clang on the following code: void func(unsigned n) { > for (unsigned long x = 1; x < n; ++x) > dummy(x); > } I get the following llvm ir: define void @func(i32 %n) { > entry: > %conv = zext i32 %n to i64 > %cmp5 = icmp ugt i32 %n, 1 > br i1 %cmp5, label %for.body, label %for.cond.cleanup > for.cond.cleanup:

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:

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, I have a SCEV like this: {16,+,8}. Say that this came from a loop like: int64_t *p; for (int64_t i = 0; i < ...; ++i) p[i+2]... And assuming that I'm on a 64-bit machine. What I would like to do is normalize it like that, basically this: {2,+,1} i.e. map it to the index. Now, I tried to get the underlying element size of the pointer, then getUDivExpr(OriginalSCEV, ElementSize); But

Hello, I have an optimisation issue in an llvm IR pass - the issue being that unnecessary instructions are generated in the final assembly (with -O3). I want to create the following assembly snippet: mov dl,BYTE PTR [rsi+rdi*1] add dl,0x1 adc dl,0x0 mov BYTE PTR [rsi+rdi*1],dl however what is created is (variant #1): mov dl,BYTE PTR [rsi+rdx*1] add dl,0x1 cmp

Hi Craig, On 03.07.19 17:33, Craig Topper wrote: > Don't the CreateICmp calls return a Value* with an i1 type? But then > they are added to an i8 type? Not sure that works.  I had that initially: auto cf = IRB.CreateICmpULT(Incr, ConstantInt::get(Int8Ty, 1)); auto carry = IRB.CreateZExt(cf, Int8Ty); Incr = IRB.CreateAdd(Incr, carry); it makes no difference to the generated assembly

Hi all, Let's see an example (from Alexandre Isoard) first: **************************************************************************************** ; RUN: opt -ipsccp -deadargelim -licm -O2 -S < %s @g = internal global i32 0 ; Function Attrs: argmemonly define internal void @foo(i32* nonnull dereferenceable(4) %arg, i32 %val) #0 { entry: store i32 %val, i32* %arg ret void } define

On 7/14/20 4:34 PM, Hal Finkel via llvm-dev wrote: > > On 7/14/20 11:28 AM, Fangqing Du wrote: >> Thank you Hal and Stefan! >> >> Bug report is filed: https://bugs.llvm.org/show_bug.cgi?id=46717 >> <https://bugs.llvm.org/show_bug.cgi?id=46717> >> >> And Stefan, >> I think 'attributor' is a really nice pass, and can infer more >>