search for: xform

Anyone had experience using XForms with rails? Did you have to write xform helpers? Any info would be appreciated - thanks -- Posted via http://www.ruby-forum.com/.

I remember why I didn't implement this rule in Instcombine. It add one instruction. So, this xform should be driven by a redundancy eliminator if you care code size. On 8/8/13 10:13 AM, Shuxin Yang wrote: > I did few transformation in Instruction *InstCombiner::visitFDiv() in > an attempt to remove some divs. > I may miss this case. If you need to implement this rule, it is > be...

...e, what I want, and what I get. Can someone tell me how to get what is in the 'want' column from the 'have' column programatically? tia, Matt df <- data.frame(have=c("a.b.c", "d.e.f", "g.h.i"), want=c("a","d","g")) df.xform <- transform(df, get=strsplit(as.character(have), split=".", fixed=TRUE)[[1]][1]) df.xform [[alternative HTML version deleted]]

I have tried this code : http://msdn2.microsoft.com/en-us/library/ms532658(VS.85).aspx SCALE, TRANSLATE, REFLECT do work, but ROTATE, SHEAR don't. The new PlgBlt (0.9.59) does not work too. Some hint, please ?

I did few transformation in Instruction *InstCombiner::visitFDiv() in an attempt to remove some divs. I may miss this case. If you need to implement this rule, it is better done in Instcombine than in DAG combine. Doing such xform early expose the redundancy of 1/y, which have positive impact to neighboring code, while DAG combine is bit blind. You should be very careful, reciprocal is very very very imprecise transformation. Sometimes you will see big different with and without this xform. On 8/8/13 9:25 AM, Chad Rosier...

...r the IR, just the "arcp" flag, which allows for replacement of division with reciprocal-multiply. On Aug 8, 2013, at 10:21 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > I remember why I didn't implement this rule in Instcombine. It add one instruction. So, > this xform should be driven by a redundancy eliminator if you care code size. > > On 8/8/13 10:13 AM, Shuxin Yang wrote: >> I did few transformation in Instruction *InstCombiner::visitFDiv() in an attempt to remove some divs. >> I may miss this case. If you need to implement this rule, i...

>I'm just curious as tho which concrete passes would benefit sooner. This all depends on those who are working on other loop xforms, since we currently don't have bandwidth to drive that kind of changes into other loop xforms. That's why when this line of questions pops up, I offer to work together. Short of that, the best we can proactively do is to make vectorizer analyses available outside of vectorizer (and easy to...

...for the legalizer (where it's implemented anyway)? > > Yes, the legalizer should do this transformation. Actually, perhaps not. The reason that dag combine does this is that it knows tricky ways to turn division by a constant into multiplication by a constant (plus magic). Doing this xform allows the rem case to take advantage of this. That said, I'm sure there are some targets and some cases where this is counter productive. Are you hitting one? -Chris -- http://nondot.org/sabre/ http://llvm.org/

...ast<CallInst>(dep.getInst())) { + CallSite CS = CallSite::get(C); + + /* Pointer must be a parameter (case 1) */ + if(!CS.hasArgument(pointer)) + return false; 4. Here, please do an alias check if the store's pointer operand is not the same as the load's (allowing the xform if they are must- alias). This helps in some cases where there are GEP's that are the same but not actually CSE'd: + /* Store cannot be volatile (case 2) */ + if(S->getPointerOperand() != pointer || S->isVolatile()) + return false; 5. In the logic for your xform, I d...

Hello, This patch fixes PR2218. However, I'm not pretty sure that this optimization should be in MemCpyOpt. I think that GVN is good place as well. Regards -- Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: pr2218.patch Type: application/octet-stream Size: 6146 bytes Desc: not available URL:

...be worth only by that much. I have a thought about moving vectorizer's analysis part (all the way to cost model) into Analysis. When extra precision is desired, we can utilize such an (heavier weight) Analysis. In short, my preference is to make vectorizer's analysis more usable by other xforms than making more and more loop xforms happen inside LV. In the meantime, if those who are working on LD needs our input in tuning LD cost model, I'm more than happy to pitch in. We can also discuss what part of vectorizer analysis is helpful in LD at the same time. Thanks, Hideki -----Origi...

...9;s implemented anyway)? > > > > Yes, the legalizer should do this transformation. > > Actually, perhaps not. The reason that dag combine does this is that it > knows tricky ways to turn division by a constant into multiplication by a > constant (plus magic). Doing this xform allows the rem case to take > advantage of this. That said, I'm sure there are some targets and some > cases where this is counter productive. Are you hitting one? yes. i'm compiling for a target without native div/rem instructions. when compiling expressions like (a % 3), the da...

I am confused by this bit of code in instcombine: 09789 if (GetElementPtrInst *GEPI = dyn_cast<GetElementPtrInst>(Op)) { 09790 const Value *GEPI0 = GEPI->getOperand(0); 09791 // TODO: Consider a target hook for valid address spaces for this xform. 09792 if (isa<ConstantPointerNull>(GEPI0) && 09793 cast<PointerType>(GEPI0->getType())->getAddressSpace() == 0) { 09794 // Insert a new store to null instruction before the load to indicate 09795 // that this code is not reachable. We do this ins...

On 09/13/2018 02:43 PM, Renato Golin via llvm-dev wrote: > On Thu, 13 Sep 2018 at 18:46, Saito, Hideki <hideki.saito at intel.com> wrote: >> This all depends on those who are working on other loop xforms, since we currently don't have bandwidth to drive that kind of changes into other loop xforms. That's why when this line of questions pops up, I offer to work together. Short of that, the best we can proactively do is to make vectorizer analyses available outside of vectorizer (and easy to...

..., Diego <diego.caballero at intel.com>; Florian Hahn <florian.hahn at arm.com> Subject: Re: Loop Distribution pass On Thu, 13 Sep 2018 at 18:03, Saito, Hideki <hideki.saito at intel.com> wrote: > In short, my preference is to make vectorizer's analysis more usable by other xforms than making more and more loop xforms happen inside LV. Agreed! I wasn't alluding to moving the analysis inside LV, just using it inside a V2V transform to find more options to vectorise. --renato

...ne wrote: > I am confused by this bit of code in instcombine: > > 09789 if (GetElementPtrInst *GEPI = dyn_cast<GetElementPtrInst>(Op)) { > 09790 const Value *GEPI0 = GEPI->getOperand(0); > 09791 // TODO: Consider a target hook for valid address spaces for this > xform. > 09792 if (isa<ConstantPointerNull>(GEPI0) && > 09793 cast<PointerType>(GEPI0->getType())->getAddressSpace() == 0) { > 09794 // Insert a new store to null instruction before the load to > indicate > 09795 // that this code is not re...

...ed, does not mean non affine subscripts cannot be worked with at all. They just provide less information. >> The big selling point of polyhedral transformations is uniform handling >> of several transformations. > > Right. In olden times, people use a bunch of independent loop xforms, > composed in different ways to achieve different effects. Then came the > unimodular xforms which could achieve the effect of combining several > xforms (but not all). The came the polyhedral approach, which could do > quite a bit more, including the actual dependence analysis, as l...

i have a vector with values similar to the below text [1] 001-010-001-0 I want to get rid of all leading zeroes. for example i want to change the values of the vector so that [1] 001-010-001-0 becomes [1] 1-010-001-0. Another example [1]082-232-232-1 becomes [1] 82-232-232-1 how do i do this? -- View this message in context:

...h.o hermite_curve.o element_lookup.o aa_lookup.o mol3d.o mol3d_init.o mol3d_io.o mol3d_utils.o mol3d_chain.o mol3d_secstruc.o sgi_image.o vrml.o ogl_utils.o ogl_body.o ogl_bitmap_character.o llvm-gcc -o molscript -O4 molscript.tab.o global.o lex.o col.o select.o state.o graphics.o segment.o coord.o xform.o postscript.o raster3d.o vrml.o regex.o opengl.o image.o eps_img.o sgi_img.o jpeg_img.o png_img.o clib/clib.a \ -L/sw/lib -lglut -lGLU -lGL /System/Library/Frameworks/OpenGL.framework/Libraries/libGL.dylib -L/usr/X11R6/lib -lX11 -lXi -lXmu -L/sw/lib -ljpeg -L/sw/lib -lpng -lz -bin...

Hey llvm-dev, Continuing a discussion from D50913... A group working on the FP rounding mode and trap-safety project have run into a situation where it would make sense to add a new FNEG instruction and decouple the existing FNEG<->FSUB transformations. The IEEE-754 Standard (Section 5.5.1) makes it clear that neg(x) and sub(-0.0,x) are two different operations. The former is a bitwise