LLVM optimisation passes / tables next to code

[Gabor Greif]

llvm.order sounds a bit hackish to me. A cleaner solution might be to
add a 'placebefore' attribute to global variables (or maybe a
'placeafter' attribute on functions) naming the related entity.
Something like this:

> @foo_D = common global %struct.Descr zeroinitializer, align 8, placebefore @foo
>
> define i32 @foo() nounwind uwtable readnone {
>   ret i32 undef
> }

Cheers,

    Gabor

PS: I am weighing in, because if we start out with a hack now, the
hacky semantics must be dragged all through the lifetime of LLVM 3.x
bitcode formats.


On 2/12/12, David Terei <davidterei at gmail.com> wrote:
> On 11 February 2012 13:35, Sergiu Ivanov <unlimitedscolobb at gmail.com> wrote:
>> Hello,
>>
>> Looks like I'm back online :-)
>>
>> There's still plenty of time before any of GSoC deadlines,
>> fortunately.  In fact, according to the official timeline
>> (http://bit.ly/zw1Gle), organisations aren't even allowed to submit
>> their own applications yet.
>>
>> On Fri, Feb 10, 2012 at 12:34 AM, David Terei <davidterei at gmail.com>
>> wrote:
>>>
>>> Welcome to the wonderful and painful world of GHC hacking :)
>>
>> Thank you, I hope it's going to be painfully wonderful :-)
>>
>>> If GHC decides to accept you and for the project you propose then
>>> I'd probably be the mentor. I think this is a good project to get
>>> done but also a risky one. We've had mixed SoC results and have
>>> progressively tried to put students onto more defined and straight
>>> forward tasks.
>>
>> Hm, I see.  I can only appreciate of the convergence of task
>> formulations to something more concrete.
>>
>>> The hacking would also be nearly 100% C++ as its the LLVM code base
>>> you need to change not GHC's so much.
>>
>> Yes, that's what I would guess; but I feel too curious about the
>> project :-) I once had extensive experience with C++; I'm not that
>> up-to-date now, but there shouldn't be any trouble with that.
>>
>>> If you're keen on this though I'd suggest you do the following to get
>>> some traction to show you could handle this as a project:
>>>
>>> 1. Read this bug ticket:
>>> http://hackage.haskell.org/trac/ghc/ticket/4213, I've put a short
>>> explanation of how I'd tackle this task.
>>>
>>> 2. Talk to the LLVM developers (please CC me on the emails). They will
>>> know if the method I propose are good or not and how keen they are to
>>> accept patches.
>>
>> To gain at least some basic perspective over the situation I read:
>> http://llvm.org/docs/LangRef.html and
>> llvm.org/pubs/2010-09-HASKELLSYM-LLVM-GHC.pdf , the latter being your
>> article entitled "An LLVM Backend for GHC".  Your article proved very
>> helpful in that it effectively lifted me up from zero-level knowledge.
>>
>> Before I actually tell the LLVM folk anything, I'd like to double
>> check my understanding of the matters by producing a summary of what I
>> have in my head.
>>
>> GHC uses TNTC to reduce the invocation of a closure to a single
>> pointer lookup.  LLVM does not explicitly offer any control over how
>> the data and text sections are arranged.  The point of the project is
>> to make LLVM handle this in a way or another.
>>
>> You have suggested two solutions:
>>
>> 1. Implement another special LLVM variable, llvm.order, which would
>>   list global variables and function names in the other they should
>>   appear in the object code.
>>
>> 2. Make it possible to explicitly attach a variable to a function, so
>>   that it eventually gets right before the code of the function.
>>
>> Am I getting the things correctly?
>>
>
> Yes perfectly. With the 'llvm.order' approach we also might need to
> change LLVM's code for how custom labels are handled as you can't put
> global variables into the .data section, LLVM expects you to be using
> custom labels for custom sections not for overriding the default
> behaviour and putting some data into the text section...
>
> Cheers,
> David
>
> _______________________________________________
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-ghc
>