llvm dev - Jul 2008 - [LLVMdev] Casting between address spaces and address space semantics

Hi Cédric,
> > When this information is known, we can define a "any memory"
address
> > space, which is a superset of the specific address spaces. This will
> 
> The two uses I see for memory space have completely separate memory space
> (even different instruction to access). You can't define an 'any
memory
> space', 
This is indeed similar to our architecture, different memory spaces are indeed
completely separate. This also means that the "any memory" address
space is
not actually representable in final program, but only used as an intermediate
step.
> if your memory space is already mapped on a global memory, why
> bother to use memory space  anyways...
I could also imagine a difference in performance cost. For example, if an
address space is a superset of another, loading things from the larger address
space might be more costly, but not impossible. I could imagine NUMA-type
systems to have something like this: You can access any memory address, but if
you know in advance that you are accessing local memory, faster instructions
can be emitted.
> > allow a function to be (temporarily) defined to work with any memory,
> > while still properly propagating information about the different
> > memories through the program (and preventing mixup, since you can cast
> > to the "any memory" address space, but not back).
> I think that what you want is a basic form of C++ template allowing a
> function to take any address space. Like template, these function would be
> codegened as many time as there is of different (used) combination of
> address space in there parameter (since load and store are different for
> each address space).
Yeah, this is what we are essentially trying to achieve. However, I don't
think that this feature is part of any spec at all, so we are currently trying
to implement this with a combination of forced inlining and a custom function
duplication pass.

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080719/2f6cae2c/attachment.sig>