llvm dev - Dec 2011 - [LLVMdev] [cfe-dev] Extend llvm to fix global addresses

(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.

> 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

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.