similar to: Are SCEV normal form?

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

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

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

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

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:

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

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?

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

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

Hello, I noticed that our SCEVUDiv does not simplify anything when the RHS is not a constant. Is that because there is a potential issue with division by zero being simplified? For instance, would it be okay to simplify: ((%i * %n)<nuw> /u %n) into: %i The way I see it, if %n is 0, then that division is undefined and we can "define it", at will, as being %i. Would that make

Hi all, I'm looking into resolving a FIXME in the LoopDataPrefetch (and FalkorMarkStridedAccesses) pass by marking both of these passes as preserving the ScalarEvolution analysis. Unfortunately, when this change is made, LSR will generate different code. One of the root causes seems to be that SCEV will return different nsw/nuw flags for the same Value, depending on what order the

Hi Alexandre, On Wed, Oct 19, 2016 at 6:27 PM, Alexandre Isoard <alexandre.isoard at gmail.com> wrote: > Really interesting read. I am perplexed now, and am not even sure what is > the meaning of undef anymore. Welcome aboard. :) > Example (unrelated to your blog post, but still weird): > %x = sext i1 undef to i2 > > I understand that I can replace it by either of: >

I'm translating llvm's intermediate representation, after optimization, to the intermediate representation of another optimizer. One of the problems I've run into is that llvm sometimes (although rarely) produces strangely sized integers after an opt pass with -O3 (in this example, 832 bits). I need to use 8, 16, or 32 bit integers for the other intermediate language. In short,

On 8/8/2017 1:37 PM, Friedman, Eli wrote: > On 8/8/2017 10:22 AM, Geoff Berry via llvm-dev wrote: >> Hi all, >> >> I'm looking into resolving a FIXME in the LoopDataPrefetch (and FalkorMarkStridedAccesses) pass by marking both of these passes as preserving the ScalarEvolution analysis. Unfortunately, when this change is made, LSR will generate different code. One of the

Hi Alexandre, On Wed, Oct 19, 2016 at 11:19 AM, Alexandre Isoard <alexandre.isoard at gmail.com> wrote: > I am probably missing something important, but what I mean is that you can > always convert: > > %y = xor %x, %x > to > %y = 0 > > Regardless of if %x is/might be an undef. That is, consider that reading %x > any number of times always give the value of its

Hi, This is somewhat similar to the previous thread regarding missed vectorization opportunities (http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084765.html), but maybe different enough to require a new thread. I'm seeing some missed vectorization opportunities in the loop vectorizer because SCEV is not able to fold sext/zext expressions into recurrence expressions (AddRecExpr). This

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 think canEvaluateTruncated() in InstCombiner needs use cost model to decide whether perform optimization or not. Without cost model from TargetTransformInfo, aggressively optimizing IR in vector types according to the number of bits demanded may lead to scalarization of vector operations. For example, if the input IR is: %wide.load25 = load <32 x i8>, <32 x i8>* %231, align