On 1 March 2010 21:56, Max Bolingbroke wrote:
> I forgot to mention: I wonder if it might be worth looking at link
> time optimisation, ala llvm-gcc? i.e. store LLVM bitcode in the .o
> files, and substitute the llvm linker for standard ld in order to
> generate assembly at link time. I suspect th
I forgot to mention: I wonder if it might be worth looking at link
time optimisation, ala llvm-gcc? i.e. store LLVM bitcode in the .o
files, and substitute the llvm linker for standard ld in order to
generate assembly at link time. I suspect that GHC itself is getting
most of the cross-module inlin
David replied to my query about LLVM as below, which I'm forwarding to the list.
It sounds like there are two potential LLVM based GSoC projects:
Project 1: LLVM optimisation passes
~~~
1) Clearly identify issues with LLVM produced assembly code in the
context of GHC
*
The most interesting observation seems to be that the results are
largely inconsistent (look at 'atom', for example). Even wheel-
sieve1, where our numbers go in the same direction, varies between
+10% and +22.7%. My numbers are from an older HEAD (as I had nofib
handy there), but I'm stil
Hi David,
This is great stuff of course!
I notice that you have identified some problems with the generated
code (e.g. the ESP manipulation stuff you point to at the end of
http://groups.google.com/group/llvm-dev/msg/28b99513bcc38e0f).
Do you think there are some quick wins here that could be ha
On 25/02/2010 10:57, David Terei wrote:
Simon Marlow wrote:
On 25/02/2010 02:00, David Terei wrote:
Do we envisage doing anything complex to the Llvm code inside GHC in
the
future? I can't think of a reason to.
One thing I would like to investigate at some point is to have the LLVM
binding u
Simon Marlow wrote:
On 25/02/2010 02:00, David Terei wrote:
Do we envisage doing anything complex to the Llvm code inside GHC in the
future? I can't think of a reason to.
One thing I would like to investigate at some point is to have the LLVM
binding use the C++ API of LLVM instead of printin
On 25/02/2010 02:47, David Terei wrote:
Simon Marlow wrote:
Here's a patch review.
Oh there is one other issue I keep forgetting about. LLVM requires that
all basic blocks end in a control flow statement. Cmm basic blocks have
this property for everything except the hand written cmm.
e.g rts/
On 25/02/2010 02:00, David Terei wrote:
Do we envisage doing anything complex to the Llvm code inside GHC in the
future? I can't think of a reason to.
One thing I would like to investigate at some point is to have the LLVM
binding use the C++ API of LLVM instead of printing out LLVM Assembly.
On 25/02/2010 01:15, Manuel M T Chakravarty wrote:
The most interesting observation seems to be that the results are
largely inconsistent (look at 'atom', for example). Even
wheel-sieve1, where our numbers go in the same direction, varies
between +10% and +22.7%. My numbers are from an older H
On 25/02/2010 00:08, David Terei wrote:
Simon Marlow wrote:
> So, nofib programs are on average 4-5% slower, with a 6% increase in
> binary sizes (this is with -split-objs).
>
> What's interesting is that there are some outliers here: programs that
> go 12-17% slower without TNTC. Looking at
Simon Marlow wrote:
Here's a patch review.
Oh there is one other issue I keep forgetting about. LLVM requires that
all basic blocks end in a control flow statement. Cmm basic blocks have
this property for everything except the hand written cmm.
e.g rts/Apply.cmm has the code:
INFO_TABLE(
Simon Marlow wrote:
In fact, I'm surprised at how much there is here. The LLVM backend has
more in common with the native code generators than the C backend, but I
was expecting something closer to a straightforward pretty-printer. I
wonder if having a complete datatype for LLVM is really buying
Simon Marlow:
> On 22/02/2010 16:49, Simon Marlow wrote:
>> On 22/02/2010 12:34, Simon Marlow wrote:
>>
>>> I'm currently running some benchmarks to see how much impact turning off
>>> TNTC has on the -fasm backend.
>>
>> Here are the results on x86-64/Linux:
> [ snip ]
>> ---
Simon Marlow wrote:
> So, nofib programs are on average 4-5% slower, with a 6% increase in
> binary sizes (this is with -split-objs).
>
> What's interesting is that there are some outliers here: programs that
> go 12-17% slower without TNTC. Looking at David's thesis the results are
> quite differ
davidterei:
> On 24 February 2010 12:38, Don Stewart wrote:
> > David,
> >
> > Did you see my patch to fix the parsing of -optlo and friends?
> >
> > http://www.galois.com/~dons/add-new-llvm-code-generator-to-ghc_.dpatch
> >
> > Order of the flags appears to matter to GetOpt.
> >
>
> Great! Th
On 22/02/2010 16:49, Simon Marlow wrote:
On 22/02/2010 12:34, Simon Marlow wrote:
I'm currently running some benchmarks to see how much impact turning off
TNTC has on the -fasm backend.
Here are the results on x86-64/Linux:
[ snip ]
--
On 24 February 2010 12:38, Don Stewart wrote:
> David,
>
> Did you see my patch to fix the parsing of -optlo and friends?
>
> http://www.galois.com/~dons/add-new-llvm-code-generator-to-ghc_.dpatch
>
> Order of the flags appears to matter to GetOpt.
>
Great! Thanks for that. I remember fixing t
On 22 February 2010 23:34, Simon Marlow wrote:
> I presume the calling-convention changes can be made in an acceptable way,
> by defining a new calling convention rather than modifying the exisitng C
> one? Does LLVM allow new calling conventions to be defined dynamically,
> without patchig LLVM
David,
Did you see my patch to fix the parsing of -optlo and friends?
http://www.galois.com/~dons/add-new-llvm-code-generator-to-ghc_.dpatch
Order of the flags appears to matter to GetOpt.
-- Don
davidterei:
> David Peixotto wrote:
>> I "deprecated" the LlvmBackend page in favor of Comment
David Peixotto wrote:
I "deprecated" the LlvmBackend page in favor of Commentary/Backends/LLVM by
putting a forwarding reference to the latter. Otherwise I left the current LlvmBackend
page intact, but can remove it once David agrees the important info has been transferred.
OK, have checked o
On 23/02/10 17:31, Isaac Dupree wrote:
On 02/23/10 10:21, Simon Marlow wrote:
+Flag unreg
+ Description: Build an unregistered version.
it's called
"unregisterized", is it not? (vs.
"unregistered"
). Yes,
"unregisterised"
is not a word outside the world of GHC (and I'm not sure if we use "s"
o
On 02/23/10 10:21, Simon Marlow wrote:
+Flag unreg
+ Description: Build an unregistered version.
it's called
"unregisterized", is it not? (vs.
"unregistered"
). Yes,
"unregisterised"
is not a word outside the world of GHC (and I'm not sure if we use "s"
or "z")
-Isaac
__
On 18/02/2010 23:55, David Terei wrote:
Hi all,
Over the last 6 months I've been working on a new code generator for GHC
which targets the LLVM compiler infrastructure. Most of the work was
done as part of an honours thesis at the University of New South Wales
under the supervision of Manuel Cha
On 21 February 2010 04:17, David Peixotto wrote:
> 1) It would be nice if -ddump-llvm implies -fllvm. My first test was to try
> -ddump-llvm and it produced no output (without the -fllvm flag).
Yep sure, thanks for the pick up.
> 2) Do you expect the llvm backend to work with the -dynamic ghc f
On 22 February 2010 00:09, Malcolm Wallace
wrote:
> There is already a published Haskell binding for LLVM on Hackage. Does your
> new binding cover the same territory? Or different aspects? Could it be
> converted to use the existing binding? Or could your features be merged
> with theirs?
A
On Feb 22, 2010, at 4:53 PM, Simon Marlow wrote:
>> I started to do this for you, but in doing so I found a link to another LLVM
>> page:
>> http://hackage.haskell.org/trac/ghc/wiki/LlvmBackend
>>
>> No point in having two! Perhaps you can connect them together somehow?
>
> Agreed, there'
On 22/02/10 16:47, Simon Peyton-Jones wrote:
| 3) I started a page on the GHC wiki for the LLVM backend that copies the
relevant
| info from your initial email. Hope this small head start makes it easier for
| everyone to add more documentation in the future. You can find it at:
| http://hackage
On 22/02/2010 12:34, Simon Marlow wrote:
I'm currently running some benchmarks to see how much impact turning off
TNTC has on the -fasm backend.
Here are the results on x86-64/Linux:
Program Siz
| 3) I started a page on the GHC wiki for the LLVM backend that copies the
relevant
| info from your initial email. Hope this small head start makes it easier for
| everyone to add more documentation in the future. You can find it at:
| http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/
On 20 February 2010 00:30, Krasimir Angelov wrote:
> I am just curious. What had to be changed in LLVM? Could it be useful
> for other projects using LLVM?
In the C and native code generator back-end GHC stores some variables
permanently in registers for speed reasons due to how frequently they
a
First of all, congrats to David on getting this to the point where it
can be merged. Nice work!
It's clear we want this in GHC, so let's look at what needs to be done,
and the potential sticking points.
We should make LLVM optional for the time being, since it entails
turning off TABLES_NEX
On 19 February 2010 16:31, Ben Lippmeier wrote:
]> One question:
> When you set GhcWithLlvmCodeGen = YES
> should that enable -fllvm for the stage 1 compiler as well?
Yes.
> "inplace/bin/ghc-stage1" -M -include-pkg-deps -dep-makefile
> libraries/dph/dph-par/dist-install/build/.depend-v-p-dyn.ha
2. The back-end has a LLVM binding of sorts, ... Should this
binding be split out into a separate library?
There is already a published Haskell binding for LLVM on Hackage.
Does your new binding cover the same territory? Or different
aspects? Could it be converted to use the existing bin
Hi David,
This looks like great work! Thanks for making this contribution available. I
followed your instructions and was able to get the llvm backend up and running.
Just a few comments.
1) It would be nice if -ddump-llvm implies -fllvm. My first test was to try
-ddump-llvm and it produced no
On Fri, Feb 19, 2010 at 01:25:58PM +1100, Manuel M T Chakravarty wrote:
> David wrote,
>
> > 2. The back-end has a LLVM binding of sorts, this binding is similar in
> > design to say the Cmm representation used in GHC. It represents the LLVM
> > Assembly language using a collection of data types
I am just curious. What had to be changed in LLVM? Could it be useful
for other projects using LLVM?
On Fri, Feb 19, 2010 at 12:55 AM, David Terei wrote:
> Hi all,
>
> Over the last 6 months I've been working on a new code generator for GHC
> which targets the LLVM compiler infrastructure. Most
I've built this fine on X86/Linux, and I'll check it on SPARC/Solaris after I
fix the latest head breakage (and after that I'm forming the official "I hate
#ifdef" club...)
One question:
When you set GhcWithLlvmCodeGen = YES
should that enable -fllvm for the stage 1 compiler as well?
I ask bec
Felipe Lessa wrote:
I glanced over your patch and it seems you have broken LLVM's
backend. I'm not a LLVM expert by no means, but if GHC's needs
were implemented as a subtarget, wouldn't there be the
possibility of upstream LLVM accepting the patch? If the patch
didn't break the rest of LLVM th
On Fri, Feb 19, 2010 at 10:55:08AM +1100, David Terei wrote:
> http://www.cse.unsw.edu.au/~davidt/downloads/llvm-ghc.patch
I glanced over your patch and it seems you have broken LLVM's
backend. I'm not a LLVM expert by no means, but if GHC's needs
were implemented as a subtarget, wouldn't there b
David wrote,
> Issues
> --
> Issues that might need to be resolved before merging the patch:
>
> 1. Developed in isolation by 1 person with no Haskell knowledge at first. So
> usual issues with that may apply, misused data structures, bad style... ect.
> Criticisms of the code are very welco
41 matches
Mail list logo
