(resent due to mailing list breakage) On Dec 6, 2011, at 6:55 AM, Joerg Sonnenberger wrote:> On Mon, Dec 05, 2011 at 07:18:36PM -0800, Peter Cooper wrote: >> It would be nice to add support for placing globals at fixed addresses in memory. > > I don't know. From my experience, the usefulness is very, very limited. > As in: drivers are about the only thing that can make use of it.I agree that most code does not profit from specifying fixed addresses for objects. Nonetheless, there is code which does. Obvious examples: - boot-loaders - kernels - drivers - JITted code interacting with the runtime - code working with specialized address spaces>> For example, low level driver code tends to contain things like this >> >> *(int*)0x00001000 >> >> which is horrible. > > The drivers I have seen can't work that way because they are written to > cover more than one specific machine. As soon as you go anywhere near an > IO abstraction, this doesn't apply anymore. As such, I think this > feature primarily helps making ugly, unportable code differently ugly, > unportable code.Your argument appears to be that this feature would have little use to you. Noted, I guess. We've spoken to several people who do write drivers and other code like the above, and they seem pretty enthusiastic about the idea. If you have input about how best to design this, at any of the levels Peter spelled out, that would be interesting. John.
David Blaikie
2011-Dec-06 23:23 UTC
[LLVMdev] [cfe-dev] Extend llvm to fix global addresses
> We've spoken to several people who do write drivers and > other code like the above, and they seem pretty enthusiastic about the > idea. If you have input about how best to design this, at any of the levels > Peter spelled out, that would be interesting.I'm curious what the particular benefits/differences would be between this language feature & the existing solution (casting constant integer values to pointers). This wasn't clear to me from the original post. Perhaps some (even straw man) example code? - David
Peter Cooper
2011-Dec-06 23:29 UTC
[LLVMdev] [cfe-dev] Extend llvm to fix global addresses
The best case i can think of is embedded developers needing to layout functions or globals in memory. Currently they would have to resort to a linker script or assembly hacks for this. But anything which avoids the horrible int* cast has to be a good thing. For one thing it would cause alias analysis a lot of pain. On Dec 6, 2011, at 3:23 PM, David Blaikie wrote:>> We've spoken to several people who do write drivers and >> other code like the above, and they seem pretty enthusiastic about the >> idea. If you have input about how best to design this, at any of the levels >> Peter spelled out, that would be interesting. > > I'm curious what the particular benefits/differences would be between > this language feature & the existing solution (casting constant > integer values to pointers). This wasn't clear to me from the original > post. > > Perhaps some (even straw man) example code? > > - David > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Dec 6, 2011, at 3:23 PM, David Blaikie wrote:>> We've spoken to several people who do write drivers and >> other code like the above, and they seem pretty enthusiastic about the >> idea. If you have input about how best to design this, at any of the levels >> Peter spelled out, that would be interesting. > > I'm curious what the particular benefits/differences would be between > this language feature & the existing solution (casting constant > integer values to pointers). This wasn't clear to me from the original > post.One thing that comes immediately to mind is that the optimizer would see loads and stores as affecting a specific global variable and therefore not aliasing other globals and the heap. Dereferencing a constant pointer also only really works if you're memory-mapping. If you actually need to place data at a fixed address, it's not good enough, and you'll end up needing some crazy linker magic. One of our long-term goals is to reduce the need for that. John.
Seemingly Similar Threads
- [LLVMdev] [cfe-dev] Extend llvm to fix global addresses
- [LLVMdev] [cfe-dev] Extend llvm to fix global addresses
- [LLVMdev] Extend llvm to fix global addresses
- [Openmp-dev] [cfe-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries
- [LLVMdev] Extend llvm to fix global addresses