Hello,
I am very sorry, but it seems that my time constraints have got too
severe recently, so I cannot devote the necessary amount of time to
this project :-( I do expect to have slightly more time in the summer,
but I don't think it's going to be the 40hrs/week necessary for GSoC
:-(
This proje
On Mon, Mar 19, 2012 at 12:12 PM, Simon Marlow wrote:
> I've been thinking a little about this. If some extension to LLVM is needed
> to support TNTC, then I think it might be better to go all the way and
> support arbitrary labels with info tables, not just top-level procedures.
> Also, it h
Hello,
I've seen Chris Lattner of LLVM voice in the favour of adding blobs of
inline assembler at the start of functions, which sounds like good
news!
I'll be now (quickly) reading http://llvm.org/docs/tutorial/ to get an
overall picture and I will also try to fix a bug to show that I'm
actually
On Wed, Feb 29, 2012 at 12:37 PM, Simon Marlow wrote:
>
> It's hard to say. All of the proposed solutions are a compromise of one
> kind or another, and they would all impose some kind of penalty - code size
> or speed - on the NCG too, since we have to use the same ABI. If the
> penalty can be
On Tue, Feb 21, 2012 at 8:25 AM, David Terei wrote:
>
> It has arrived at a kind of conclusion. The trick suggested by Chris
> seems like it should work, only concern would be that we can encode
> the jmp instruction in constant space (and if not how to handle by
> padding or splitting the table).
Hello,
I've been following the discussion with the LLVM developers, but the
last message I have received on that topic was about 4 days ago and it
was:
> Sure, the jump instruction is not the problem. But we were hoping to omit
> the jump instruction and have the compiler add the correct offset
Hello everyone,
On behalf of GHC hackers, I would like to discuss the possibility of
having a proper implementation of the tables-next-to-code optimisation
in LLVM.
Currently, the object code produced by all three GHC backends follows
the convention that the table with the metadata of a closure i
On Mon, Feb 13, 2012 at 2:51 PM, Gabor Greif wrote:
> 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
Hello,
Thank you for your prompt feedback!
I did plan to provide a proper answer today, but it looks like I'm
slightly ill, which prevents me from thinking properly, sorry :-( I
plan to be back online tomorrow, which is when I'll do my best to
reply adequately.
Sergiu
__
Hello everyone,
I would like to participate in GSoC-2012 with Haskell and contribute
something useful to the community. The task
http://hackage.haskell.org/trac/summer-of-code/ticket/1582 seems very
interesting to me. I was told on #haskell that I could talk about
this task with GHC devs, so her
10 matches
Mail list logo
