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

David Blaikie dblaikie at gmail.com
Tue Dec 6 15:57:30 PST 2011


> 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



More information about the cfe-dev mailing list