llvm dev - Dec 2011 - [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

> 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.
In this case you're describing a situation that's not the
constant-cast-to-int - ah, like John's recent reply, wanting to place
certain variables into fixed memory locations & let the compiler do
the initialization, etc.

For functions I realize that'd have to be compiler supported, but for
global variables what would the practical difference be between "place
this variable at this address" and "take a pointer to this constant
address & write my constant data in there" be? Is that something that
cannot be done with the latter technique?
> But anything which avoids the horrible int* cast has to be a good thing.
I'm just not sure I see it as so problematic as deserving of a
language feature - what actual problems does it cause developers? Used
fairly explicitly & in the places that require it, it doesn't seem
terribly intrusive (so as to corrupt otherwise clean code) or error
prone.
> For one thing it would cause alias analysis a lot of pain.
Hmm, I suppose - I'm not sufficiently familiar with that to know how
this would adversely affect such logic nor what optimizations might
occur on it. Wouldn't the usual use case here (for drivers, etc)
require the pointer to be volatile anyway, to avoid the compiler
optimizing away, say, a repeated read that was intentionally designed
to read distinct values due to the hardware changing the values in
memory?

[apologies if these are somewhat naive questions & feel free to carry
on without my discussion, of course]

- David

On Dec 6, 2011, at 3:29 PM, Peter Cooper wrote:
> 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.
This proposal also requires extending object file formats and linkers,
and this impacts a lot of people, so it would want a pretty
compelling motivation.
> 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.
Actually, it wouldn't cause very much pain, if any, in alias analysis.

LLVM IR already assumes that programmers can't "guess" what the
address of the stack, global variables, or heap will be. An integer
constant casted to a pointer is assumed to be non-aliasing with
"regular" objects in memory. This property is of utmost importance,
because a pass like mem2reg relies on it to know that the allocas
it wants to promote to registers don't have their addresses
secretly taken, for example.

To support global variables at fixed addreses, you'd probably
need to make an exception to this rule, to allow these variables
to be accessed via their address values directly, which would
defeat much of the remaining benefit. These variables would
always be implicitly escaped.

I don't mean to shoot you down, but there don't seem to be any
compelling motivations for this feature.

Dan