similar to: vrp

On Mon, Aug 7, 2017 at 2:14 AM, Anastasiya Ruzhanskaya via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I am trying to print it like this (maybe here is smth wrong?) > > > LazyValueInfo &LV = getAnalysis<LazyValueInfoWrapperPass>().getLVI(); > DominatorTree &DT = > getAnalysis<DominatorTreeWrapperPass>().getDomTree(); > LV.printLVI(F,

I am primarily interested in phi nodes and their induction variables, in ValueTracking file there is an analysis of them, but if the upper bound is inf, it is not working? 2017-08-07 11:41 GMT+02:00 Anastasiya Ruzhanskaya < anastasiya.ruzhanskaya at frtk.ru>: > So, it is not supported to determine by this instruction : %cmp = icmp slt > i32 %i.03, 99, > that %i.03 = phi i32 [ 0,

Hi, I have a question about ConstantRange::sub(const ConstantRange &Other) at lib/Support/ConstantRange.cpp:524. The code computes the new bounds as follows. APInt NewLower = getLower() - Other.getLower(); APInt NewUpper = getUpper() - Other.getUpper() + 1; Could someone explain this to me? I was expecting something like APInt NewLower = getLower() - Other.getUpper() + 1; APInt

Sure. I will submit a patch. BTW, what's the difference between the bounds I was expecting APInt NewLower = getLower() - Other.getUpper() + 1; APInt NewUpper = getUpper() - Other.getLower(); and the two you mentioned NewLower = Lower - (Upper-1) NewUpper = (Upper-1) - Lower + 1 They look equivalent to me. Did I miss anything? Thanks. - xi On Jun 22, 2011, at 2:39 PM, Nick Lewycky

Thanks, I think you've found a serious bug! Would you be willing to fix it? Please add a test to unittests/Support/ConstantRangeTest.cpp and then mail llvm-commits with the patch to fix it and add the test. On 20 June 2011 23:09, Xi Wang <xi.wang at gmail.com> wrote: > Hi, > > I have a question about ConstantRange::sub(const ConstantRange &Other) at >

On 22 June 2011 12:51, Xi Wang <xi.wang at gmail.com> wrote: > Sure. I will submit a patch. > > BTW, what's the difference between the bounds I was expecting > > APInt NewLower = getLower() - Other.getUpper() + 1; > APInt NewUpper = getUpper() - Other.getLower(); > > and the two you mentioned > > NewLower = Lower - (Upper-1) > NewUpper = (Upper-1) -

On Wed, Jul 23, 2014 at 4:06 PM, Rekha R <rekharamapai at nitc.ac.in> wrote: > Ok. Got it. > > If *add nsw* overflows, this results in undefined value. > But then *add* on same arguments results in well-defined value. > > Hence treating first one as redundant based on the second is acceptable. > But vice versa is not. > If they are in different code paths, sure.

> Then why does the Release Note say > " the operation is guaranteed to not overflow". It means that the person who wrote the IR has guaranteed that there's no overflow (by some means) so LLVM can assume it during optimisation. This guarantee might come from doing explicit checks before executing the add/sub; or perhaps from performing the operation after a sext so that the

Hi, I am trying to call LowerSwitchPass directly in my custom pass in this way: FunctionPass *lower = createLowerSwitchPass(); lower->runOnFunction(*f); But it will crash when running lower->runOnFunction(*f) in llvm-9. I was using this method in llvm-8 and it worked fine. It seems the crash happens at the first line of the LowerSwitch::runOnFunction(Function &F) in the newer

Hi, I am trying to understand the semantics of Instructions in llvm. Are the following instructions semantically same? * %add2 = add nsw i32 %add, %add1 %add3 = add i32 %add, %add1* Based on my understanding from the Language Reference Manual, I think they are different. But then why is the *gvn* pass detecting *%add3* as redundant and deleting it? Your views are appreciated. Rekha

There is no “switch” instruction in the target object code. It usually gets compiled into a switch table with instructions to load from it. Afaik Zhang > 在 2019年12月26日，17:49，n3v3rm03 via llvm-dev <llvm-dev at lists.llvm.org> 写道： > > Sorry I found an early thread discussing this question. I guess I shouldn't create lower switch pass like this. > However, I have another

IMHO; On undefined behaviour we can do whatever we want. If the "add nsw" overflows this would lead to undefined behaviour. Therefore we can assume that "add", with the same arguments will not overflow. On Wed, Jul 23, 2014 at 3:32 PM, Tim Northover <t.p.northover at gmail.com> wrote: > On 23 July 2014 06:25, Rekha R <rekharamapai at nitc.ac.in> wrote: >

Hi, I am not able to understand the No Signed Wrap property. My problem is in the Instruction combiner which combines two operations - add1 = add 'nsw' x 5 add2 = add 'nsw' add1 1 into add2 = add x 6. // No 'nsw' property in the combined operation. >From the comments in the Instruction Combiner I can see that the nsw flag / property is "conservatively

Hi R-devel, If you did read my survey on Rhelp about reporting, you may have seen that I am implementing a way to handle outputs for R (mainly target output destinations: xHTML and TeX). In fact: I does have something that works for basic objects, entirely done with S4 classes, with the results visible at: http://www.stat.ucl.ac.be/ROMA/sample.htm http://www.stat.ucl.ac.be/ROMA/sample.pdf To

Maybe it would illustrative to give an IR example of the case I'm interested in. Consider define void @"julia_transform_bvn_derivs_hessian!"(double* %data, double* %data2, double *%data3, double *%out) { %element11 = getelementptr inbounds double, double* %data, i32 1 %load10 = load double, double* %data %load11 = load double, double* %element11 %element21 =

Hi Arnold, Thanks for your reply. I tried test case as suggested by you. *void foo(int *a, int *sum) {*sum = a[0]+a[1]+a[2]+a[3]+a[4]+a[5]+a[6]+a[7]+a[8]+a[9]+a[10]+a[11]+a[12]+a[13]+a[14]+a[15];}* so that it has a 'store' in its IR. *IR before vectorization :*target datalayout = "e-m:e-p:32:32-f64:32:64-f80:32-n8:16:32-S128" target triple =

Hi Pranav, > I am not able to understand the No Signed Wrap property. My problem is in the > Instruction combiner which combines two operations - > add1 = add 'nsw' x 5 > add2 = add 'nsw' add1 1 > into > add2 = add x 6. // No 'nsw' property in the combined operation. > > From the comments in the Instruction Combiner I can see that the nsw flag /

Hi Suyog, Thanks for looking at this. This has recently got itself onto my TODO list too. > I am not sure how much all this will improve the code quality for horizontal reduction > (donno how frequently such pattern of horizontal reduction from same array occurs in real world/SPECS). Actually the main loop of 470.lbm can be SLP vectorized like this. We have three parts to it: A fully

On Fri, 23 Jun 2017 14:46:21 +0200, Stephan Bosch stated: >Op 21-6-2017 om 19:16 schreef lejeczek: >> hi fellas >> >> generic construct for(if possible): reply vacation message if >> address is not from add1 at com1 add2 at com2 >> >> would you share? > >require "vacation"; > >if not address "from" ["add1 at com1",

hi fellas generic construct for(if possible): reply vacation message if address is not from add1 at com1 add2 at com2 would you share? many thanks L.