2001-02-13-Reference-Memory.txt 1.7 KB

123456789101112131415161718192021222324252627282930313233343536373839
  1. Date: Tue, 13 Feb 2001 13:29:52 -0600 (CST)
  2. From: Chris Lattner <sabre@nondot.org>
  3. To: Vikram S. Adve <vadve@cs.uiuc.edu>
  4. Subject: LLVM Concerns...
  5. I've updated the documentation to include load store and allocation
  6. instructions (please take a look and let me know if I'm on the right
  7. track):
  8. file:/home/vadve/lattner/llvm/docs/LangRef.html#memoryops
  9. I have a couple of concerns I would like to bring up:
  10. 1. Reference types
  11. Right now, I've spec'd out the language to have a pointer type, which
  12. works fine for lots of stuff... except that Java really has
  13. references: constrained pointers that cannot be manipulated: added and
  14. subtracted, moved, etc... Do we want to have a type like this? It
  15. could be very nice for analysis (pointer always points to the start of
  16. an object, etc...) and more closely matches Java semantics. The
  17. pointer type would be kept for C++ like semantics. Through analysis,
  18. C++ pointers could be promoted to references in the LLVM
  19. representation.
  20. 2. Our "implicit" memory references in assembly language:
  21. After thinking about it, this model has two problems:
  22. A. If you do pointer analysis and realize that two stores are
  23. independent and can share the same memory source object, there is
  24. no way to represent this in either the bytecode or assembly.
  25. B. When parsing assembly/bytecode, we effectively have to do a full
  26. SSA generation/PHI node insertion pass to build the dependencies
  27. when we don't want the "pinned" representation. This is not
  28. cool.
  29. I'm tempted to make memory references explicit in both the assembly and
  30. bytecode to get around this... what do you think?
  31. -Chris