search for: global_memory

Hi, Daniel, thank you for your advice. Yes, ALL_MEMORY points to ALL_MEMORY. We use MD(memory descriptor) to abstract a memory location.  MD contains 4 main fields: id, base, offset, size. For these special MD (ALL_MEMORY, GLOBAL_MEMORY, STACK_MEMORY, HEAP_MEMORY),  we give them id 1, 2, 3, 4, that means MD1 is ALL_MEMORY, MD2 is GLOBAL_MEMORY, the same goes for the rest.  Then we maintain a BITSET class to encapsulate the 'union', 'intersect', 'diff' etc to simply the operations bewteen special  MD and oth...

Hi, John I am building a flow sensitive intra-procedural alias analysis(without interprocedural info). So, the first thing I have to consider is where a parameter-pointer or a global-pointer might point to. Then I defined several special Virtual Memory Locations: ALL_MEMORY, GLOBAL_MEMORY, STACK_MEMORY, HEAP_MEMORY. ALL_MEMORY contains GLOBAL_MEMORY, STACK_MEMORY, HEAP_MEMORY. e.g1: extern int * q; void f(int * p) { int a; *p = 0; //STMT1 *q = a; //STMT2 } For above case, both p and q pointed to ALL_MEMORY: p->ALL_MEMORY, q->ALL_MEMORY. And each STMT h...

...Su <steven_known at yahoo.com.cn> wrote: > Hi, Daniel, thank you for your advice. > Yes, ALL_MEMORY points to ALL_MEMORY. > > We use MD(memory descriptor) to abstract a memory location. > MD contains 4 main fields: id, base, offset, size. > For these special MD (ALL_MEMORY, GLOBAL_MEMORY, STACK_MEMORY, HEAP_MEMORY), > we give them id 1, 2, 3, 4, that means MD1 is ALL_MEMORY, MD2 is GLOBAL_MEMORY, the same goes for the rest. > Then we maintain a BITSET class to encapsulate the 'union', 'intersect', 'diff' etc to simply the operations bewteen special &gt...

...I am building a flow sensitive intra-procedural alias analysis(without interprocedural info). > So, the first thing I have to consider is where a parameter-pointer or a global-pointer might point to. > Then I defined several special Virtual Memory Locations: ALL_MEMORY, GLOBAL_MEMORY, STACK_MEMORY, HEAP_MEMORY. ALL_MEMORY contains GLOBAL_MEMORY, STACK_MEMORY, HEAP_MEMORY. Contains or points to? ALL_MEMORY should point to ALL_MEMORY, otherwise *ALL_MEMORY != ALL_MEMORY, which will break things like linked lists. In any case, the final representation in GCC of points to anyt...

On 3/13/13 4:06 AM, Steven Su wrote: > Hello, could any one point me following question. Without any context, your question is difficult to answer. Are you building a points-to analysis and wanting to know how an alias analysis might encode the fact that a pointer could alias any other pointer? -- John T. > > e.g: > void foo(int * p) > { > *p = 0; > } >

Hello, could any one point me following question. e.g: void foo(int * p) { *p = 0; } Here 'p' may point to all memory location. Could you tell me how to represent the POINT TO set of 'p'? Here is my solution: Introduce a memory-class named: Global_Mem, then p pointed to global_mem. And the MOD set of '*p=0' is

...really going to choose 2 (from what you said earlier), but the backend just needs to know how to load/store a local. So perhaps the front-end should really be generating metadata which tells the target what address space it chose for a memory space. That is !private_memory = metadata !{ i32 0 } !global_memory = metadata !{ i32 1 } !local_memory = metadata !{ i32 2 } !constant_memory = metadata !{ i32 3 } Unfortunately you’d have to essentially reserve those metadata names for your use (better names than i chose of course), but this might be reasonable. You could alternately use the example I first gav...

...the backend just needs to know how to load/store a local. > > > > So perhaps the front-end should really be generating metadata which tells > > the target what address space it chose for a memory space. That is > > > > !private_memory = metadata !{ i32 0 } > > !global_memory = metadata !{ i32 1 } > > !local_memory = metadata !{ i32 2 } > > !constant_memory = metadata !{ i32 3 } > > > > This is specific to an OpenCL front-end. How would this translate to a > language with a different memory hierarchy? > > I would also like to preserve...

...at you said earlier), but the backend just needs to know how > to load/store a local. > > So perhaps the front-end should really be generating metadata which > tells the target what address space it chose for a memory space. That is > > !private_memory = metadata !{ i32 0 } > !global_memory = metadata !{ i32 1 } > !local_memory = metadata !{ i32 2 } > !constant_memory = metadata !{ i32 3 } > > Unfortunately you’d have to essentially reserve those metadata names for > your use (better names than i chose of course), but this might be > reasonable. You could alternatel...

...at you > said earlier), but the backend just needs to know how to load/store a local. > > So perhaps the front-end should really be generating metadata which tells > the target what address space it chose for a memory space. That is > > !private_memory = metadata !{ i32 0 } > !global_memory = metadata !{ i32 1 } > !local_memory = metadata !{ i32 2 } > !constant_memory = metadata !{ i32 3 } > This is specific to an OpenCL front-end. How would this translate to a language with a different memory hierarchy? I would also like to preserve the ability for front-ends to directly...

...> backend just needs to know how to load/store a local. > > So perhaps the front-end should really be generating metadata which > tells the target what address space it chose for a memory space. > That is > > !private_memory = metadata !{ i32 0 } > !global_memory = metadata !{ i32 1 } > !local_memory = metadata !{ i32 2 } > !constant_memory = metadata !{ i32 3 } > > > This is specific to an OpenCL front-end. How would this translate to a > language with a different memory hierarchy? > > I would also like to preserve the abil...

On 08/08/2013 03:16 AM, Pete Cooper wrote: > > On Aug 7, 2013, at 5:12 PM, Michele Scandale <michele.scandale at gmail.com> wrote: > >> On 08/08/2013 02:02 AM, Justin Holewinski wrote: >>> This worries me a bit. This would introduce language-specific >>> processing into SelectionDAG. OpenCL maps address spaces one way, other >>> languages map them

On Aug 7, 2013, at 5:12 PM, Michele Scandale <michele.scandale at gmail.com> wrote: > On 08/08/2013 02:02 AM, Justin Holewinski wrote: >> This worries me a bit. This would introduce language-specific >> processing into SelectionDAG. OpenCL maps address spaces one way, other >> languages map them in other ways. Currently, it is the job of the >> front-end to map

...backend just needs to know how >> to load/store a local. >> >> So perhaps the front-end should really be generating metadata which >> tells the target what address space it chose for a memory space. That is >> >> !private_memory = metadata !{ i32 0 } >> !global_memory = metadata !{ i32 1 } >> !local_memory = metadata !{ i32 2 } >> !constant_memory = metadata !{ i32 3 } >> >> Unfortunately you’d have to essentially reserve those metadata names for >> your use (better names than i chose of course), but this might be >> reasonab...