similar to: DiagnosticInfo and SCEV

Hello, Is there a way to dump the Module IR with the SCEV as comment at the end of each line? The -analyze or -debug-pass is not printed on the IR itself. Maybe through the DiagnosticInfo? -- *Alexandre Isoard* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180322/e178b4c8/attachment.html>

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

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

Hello, I was doing some experiments with SCEV and especially the loop trip count. Sorry for the dumb question, what is the easiest way to dump SCEV analysis results on a .bc file? On a side note, I wanted to see if we could optimize this function: unsigned long kernel(long w, long h, long d) { unsigned long count = 0; for(int i = 0; i < w; ++i) for(int j = i; j < h; ++j) for(int k = j; k

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

On 3/22/2018 6:29 PM, Alexandre Isoard via llvm-dev wrote: > Hello, > > Is there a way to dump the Module IR with the SCEV as comment at the > end of each line? AssemblyAnnotationWriter exists, but I don't think anyone has hooked it up to SCEV, specifically. -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,

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:

Hello, We have some transformations based on SCEV and they usually end-up making heuristic decision based on SCEV comparison. While there are some situations where the comparison is trivial (subtract then look at the sign of the range), there are also a lot of situation where it is not (the range contains 0 strictly [aka. not on the boundary]). And we then take a "default" choice. To

Linearized array addresses are an issue in loop nest transformation. To alleviate the same, a multidimensional array indexing intrinsics have been proposed recently in the llvmp-dev mailing list [1]. From the mailing thread, it looks like there is a consensus on using intrinsics for communicating dimensions [2]. While working with our own loop transformation framework, we did a similar work on

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

Hello, I use SCEVExpander and IRBuilder to generate some code and I frequently end-up breaking dominance because the SCEVExpander insertion point and the IRBuilder insertion point do not advance in synchrony. Ideally, I could build a SCEVExpander based on an existing IRBuilder (so that they move each other). Or even better, SCEVExpander inherit from IRBuilder and basically extend it with SCEV

If count > MAX_UINT-4 your loop loops indefinitely with an increment of 4, I think. On Thu, Oct 13, 2016 at 4:42 PM, Charith Mendis via llvm-dev < llvm-dev at lists.llvm.org> wrote: > So, I tried unrolling the following simple loop. > > int unroll(unsigned * a, unsigned * b, unsigned *c, unsigned count){ > > for(unsigned i=0; i<count; i++){ > > a[i] =

Hi Alex, Sanjoy, exposing the internal IRBuilder to users of SCEVExpander violates information hiding, and encourages the tight coupling that makes code bases such as Polly so hard to maintain. SCEVExpander::expandCodeFor returns a Value that (if it's an instruction) can be used to update the insert point of the client's IRBuilder. Is that not enough? No hidden state, no hidden state

Hi, As far as I understand, AssumptionTracker is just a compile-time optimization to avoid having to iterate over instructions to find a relevant @llvm.assume. In case of @llvm.expect, one can just look up the definition, which would be the @llvm.expect. Some time ago there was a patch that replaced AssumptionTracker but got reverted. I see an issue with @llvm.expect's design. It should not

Hi Alexandre, Sorry I missed this -- I was on vacation when you sent this. SCEVExpander already has an IRBuilder in it but AFAICT it isn't exposed as a public interface. I'd be fine if you wanted to expose a public `GetIRBuilder()` accessor that let a SCEVExpander client use the same IRBuilder as SCEVExpander. -- Sanjoy On Fri, Apr 6, 2018 at 10:55 AM, Alexandre Isoard via llvm-dev

Hey, Alternatively, expose a SCEVExpander::getInsertPoint? This would proxy the underlying IRbuilder, with no real state sharing, other than the current insert point. This will be less ugly than recieving the expanded SCEV value, casting to an instruction, and feeding this to the IRBuilder. Cheers, siddharth On Thu 3 May, 2018, 15:36 Philip Pfaffe via llvm-dev, < llvm-dev at

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:

Hi folks, I'm trying to analyse this piece of IR: for.body: ; preds = %for.body, %entry %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next, %for.body ] %0 = shl nsw i64 %indvars.iv, 1 %arrayidx = getelementptr inbounds i32* %b, i64 %0 %1 = load i32* %arrayidx, align 4, !tbaa !1 %add = add nsw i32 %1, %I %arrayidx3 = getelementptr