[LLVMdev] Adding support to LLVM for data & code layout (needed by GHC)

[David Terei]

Its good to see that a feature of this nature would be useful to a
whole range of people, I wasn't aware of that.

On 9 June 2010 22:40, Andrew Lenharth <andrewl at lenharth.org> wrote:
> My argument amounts to express side tables as side tables in the IR
> rather than as an ordering on globals.  I think that would simplify
> the backend (a side table is something you discover form the function
> rather than having to check another global).  Also, if well specified,
> I think you could allow basic block labels into structures which makes
> them more interesting for other uses.

Sure. I wasn't set on the third approach I suggested, which is to have
them expressed as side tables in the IR as I didn't realise other
users would be interested in them so I didn't think it would be
appropriate to add new language constructs for one user. I don't think
it would simpler to implement in the backend though and this approach
would need changes to the frontend, so a lot more work.

What I am hoping someone may be able to give a answer to though is
what issues there may be if the second approach was taken (using the
special glob var)? Would the optimiser be tempted at some point to
replace a load instruction to an unknown address created by a negative
offset from a function with unreachable for example as Eugene
suggested may be possible?

Also, what are you gaining going with the third approach? I guess the
optimiser could do things like constant propogation using the third
approach but not the second although I think thats unlikely do give
much benefit in the kind of code GHC produces but there is everyone
else to think of :).

Thanks for all the responses though, I'm going to start playing around
with some code and see what happens.