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
No worries, thanks for being honest about this and letting us know early.
On 28 March 2012 07:45, Sergiu Ivanov unlimitedscol...@gmail.com wrote:
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
On Mon, Mar 19, 2012 at 12:12 PM, Simon Marlow simon...@microsoft.com
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
On Mon, Mar 19, 2012 at 12:12 PM, Simon Marlow simon...@microsoft.com 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
, unless we can find a way to do
this with LLVM too.
Cheers,
Simon
-Original Message-
From: David Terei [mailto:davidte...@gmail.com]
Sent: 18 March 2012 23:39
To: Sergiu Ivanov
Cc: Simon Marlow; Simon Marlow; Cvs-ghc@haskell.org
Subject: Re: LLVM optimisation passes / tables
Sounds fine. However it may be best to start with the native code
generator (NCG). It will also need to be changed to make sure the
backends are all compatible. It probably is easier to work with to
implement the proposed TNTC alternative. Can then test this
alternative works and with good
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 29/02/2012 12:06, Sergiu Ivanov wrote:
On Wed, Feb 29, 2012 at 12:37 PM, Simon Marlowmarlo...@gmail.com 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,
On 21/02/2012 06:25, David Terei wrote:
On 20 February 2012 23:19, Sergiu Ivanovunlimitedscol...@gmail.com wrote:
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
On Wed, Feb 29, 2012 at 12:37 PM, Simon Marlow marlo...@gmail.com 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
On Tue, Feb 21, 2012 at 8:25 AM, David Terei davidte...@gmail.com 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
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
On 20 February 2012 23:19, Sergiu Ivanov unlimitedscol...@gmail.com wrote:
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
On Mon, Feb 13, 2012 at 2:51 PM, Gabor Greif ggr...@gmail.com 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
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
Hi Sergiu,
Welcome to the wonderful and painful world of GHC hacking :) 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
16 matches
Mail list logo