search for: baseptr

...r why this test even exists: it does not attempt to compare the underlying object sets to test for an alias, and the volatility check should cover all this-object-is-not-quite-memory situations. As a simple example of why this matters, suppose that you have a function like this: void doit(int *baseptr) { baseptr[0] = 1; // store 1 baseptr[1] = 2; // store 2 } In this example, stores 1 and 2 can be freely re-ordered. However, isUnsafeMemoryObject reports true because the underlying objects (formal parameter 'baseptr') do not satisfy IsIdentifiedObject. Nonetheless, BasicAlias...

...it. > I've added some missing files, removed LLVMBuilder.h and added IRBuilder.h and added the BrainF example (as I had to make changes to it for the patch). The only changes that I'm not 100% happy with are the ShadowStackCollector changes. The code will currently assert if the BasePtr passed in to the ShadowStackCollector is a constant as the GEP will be a constant. If we want to make the ShadowStackCollector support constant folding, more changes are required. None of the tests in the DejaGNU test suite or the full llvm test-suite have asserted, so I have to believe this is...

Hi Dominic, +//===-- llvm/Support/IRBuilder.h - Builder for LLVM Instrs -----*- C++ -*-===// is this line the right length? It seems shorter than the similar lines below like this one: +//===----------------------------------------------------------------------===// + GetElementPtrInst *CreateStructGEP(Value *Ptr, unsigned Idx, + const char *Name =

...ore and friends non-default. I've already caught one bug in the XCore backend by doing this: if (Offset % 4 == 0) { // We've managed to infer better alignment information than the load // already has. Use an aligned load. return DAG.getLoad(getPointerTy(), dl, Chain, BasePtr, NULL, 4, false, false, 0); } Whoops! There's no alignment info being set here! Is there any reason to keep these as default arguments? It invites silent coding errors. I did this because I have to propagate the non-temporal information through various phases...

...0x6000022000[010] = 13091001 (va=6000010000 000 180 000 010) vm_enter:895: about to instantiate new maps pml4=0x6000010000 vm_enter:901: Using physical pml4 0x13091000 for Xen (XEN) mm.c:1664:d72 Bad type (saw 00000000e8000001 != exp 0000000080000000) for mfn 13091 (pfn 10) (XEN) mm.c:1724:d72 New baseptr 13091: slow path via idle pagetables (XEN) mm.c:1664:d72 Bad type (saw 00000000e8000001 != exp 0000000080000000) for mfn 13091 (pfn 10) (XEN) mm.c:1737:d72 Fatal error while installing new baseptr 13091 I''ve tried both with and without the writable page tables turned on with vm_assist....

...> I've already caught one bug in the XCore backend by doing this: > > if (Offset % 4 == 0) { > // We've managed to infer better alignment information than the load > // already has. Use an aligned load. > return DAG.getLoad(getPointerTy(), dl, Chain, BasePtr, NULL, 4, > false, false, 0); > } > > Whoops! There's no alignment info being set here! > > Is there any reason to keep these as default arguments? It invites silent > coding errors. I did this because I have to propagate the non-temporal &gt...

...e-increment loads and stores. I think that the first step is to narrow down the problematic case. In DAGCombiner::CombineToPreIndexedLoadStore, there is a loop which starts with: SmallVector<SDNode *, 16> OtherUses; if (isa<ConstantSDNode>(Offset)) for (SDNode::use_iterator I = BasePtr.getNode()->use_begin(), E = BasePtr.getNode()->use_end(); I != E; ++I) { SDNode *Use = *I; 1. Make the loop skip cases where Use->getOpcode() == ISD::ADD and then Use->getOpcode() == ISD::SUB and try to figure out whether the problem is related to folding with ADDs or SU...

Hello Hal, I have a strong suspicion that your constant folding optimization introduced at r174746 is broken on ARM. There is a bug about it: http://llvm.org/bugs/show_bug.cgi?id=15581 There is no such issue with 3.2, and reverting r174746 on top of r178740 also fixes the problem. I'm trying to fix it myself, but still have no good ideas; so it would be great to have an advice from you.

Dear community, the next step of the "Improvement of vectorization process in Polly" project is to implement the packing transformation described in http://www.cs.utexas.edu/users/flame/pubs/TOMS-BLIS-Analytical.pdf. I had a discussion with Tobias and we decided that a packing transformation is in many ways a data-layout transformation that will require to introduce a new array, copy

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

...SDValue Op, MVT NVT); - - /// Helper genWidenVectorLoads - Helper function to generate a set of - /// loads to load a vector with a resulting wider type. It takes - /// LdChain: list of chains for the load we have generated - /// Chain: incoming chain for the ld vector - /// BasePtr: base pointer to load from - /// SV: memory disambiguation source value - /// SVOffset: memory disambiugation offset - /// Alignment: alignment of the memory - /// isVolatile: volatile load - /// LdWidth: width of memory that we want to load - /// ResType: the wider re...

...dy caught one bug in the XCore backend by doing this: >> >>     if (Offset % 4 == 0) { >>       // We've managed to infer better alignment information than the load >>       // already has. Use an aligned load. >>       return DAG.getLoad(getPointerTy(), dl, Chain, BasePtr, NULL, 4, >>                          false, false, 0); >>     } >> >> Whoops!  There's no alignment info being set here! >> >> Is there any reason to keep these as default arguments?  It invites silent >> coding errors.  I did this because I have to pr...

On Feb 19, 2013, at 10:09 AM, Vesa Norilo <vnorilo at siba.fi> wrote: > Hi Nadav and Hal and thanks for the help! > > To the best of my understanding, indvars doesn't complain and an induction variable is detected. However, the loop vectorizer says: > > LV: Checking a loop in "add_vector" > LV: Found a loop: Loop > LV: Found an induction variable. >

On Thursday 11 February 2010 14:44:23 Dan Gohman wrote: > > Then we can't use it to hold a non-temporal flag. The operand might be > > non-temporal in one context but it may not be in another. > > Sharing only happens when two instructions have the "same" memory > reference info. You just need to make sure that the non-temporal > flag is significant.

On Feb 11, 2010, at 12:07 PM, David Greene wrote: > On Thursday 11 February 2010 14:02:13 Dan Gohman wrote: > >>>> Putting a bit (or multiple bits) in MachineMemOperand for this >>>> would also make sense. >>> >>> Is there any chance a MachineMemOperand will be shared by multiple >>> instructions? >> >> Yes. > > Then