Sorry, just got back to this! I've updated my tree in that github
branch to refactor the build stuff into a macro. It needs more work
but it should make it much easier to add even more experimental and
crazy analysis!
On Thu, Oct 6, 2011 at 7:00 AM, Simon Marlow wrote:
> On 04/10/2011 10:31, aust
On 04/10/2011 10:31, austin seipp wrote:
Okay, so I took a stab at the build system and getting the analysis
plugin at least building, and the results are in this commit:
https://github.com/thoughtpolice/ghc/commit/c30b32fc98a78e322d872b82bed670ee4627ecf0
I'm working on pushing a version that m
Okay, so I took a stab at the build system and getting the analysis
plugin at least building, and the results are in this commit:
https://github.com/thoughtpolice/ghc/commit/c30b32fc98a78e322d872b82bed670ee4627ecf0
I'm working on pushing a version that moves most of the logic in this
commit direc
On 30/09/2011 09:54, Max Bolingbroke wrote:
Hi GHCers,
As those of you who use the LLVM backend know, it often doesn't
optimise as aggressively as you would like. The reason for this is
often to do with aliasing. I've written a blog post outlining the
problem and a solution, in the form of a GHC
On 3 October 2011 09:49, austin seipp wrote:
> The machine is a Core i5, running Linux (2.6.38.) I haven't tested any
> of this with Max's analysis plugin because it seems to trip a bug in
> my linux build of LLVM. I'll update to a more recent LLVM revision and
> try it on my Mac OS X box, LLVM tr
I tested the greedy and PBQP register allocators with a recent GHC
HEAD (today) build and LLVM v3.0svn (revision 139459.) With nofib they
actually both give worse results than linear scan it seems.
Results of GHC's regular NCG vs LLVM:
NoFib Results
-
I've tried PBQP in the past. Not sure if I've tried with 2.9. In the
past it had compilation problems and didn't really have much of an
affect on the performance. It would be worthwhile trying again in 3.0
and with the alias analysis pass.
On 2 October 2011 10:24, Nathan Howell wrote:
> On Fri, S
On Fri, Sep 30, 2011 at 4:08 PM, David Terei wrote:
> Are you using LLVM 2.9 or the unreleased 3.0? I'm
> excited about the new register allocator in 3.0. I don't know if it
> will help but more then any other improvement in the last few releases
> it seems to have the potential to. I was hoping
On 30 September 2011 10:09, Max Bolingbroke wrote:
> On 30 September 2011 16:07, Max Bolingbroke
> wrote:
>> I just tried to run David Peixotto's fibon suite with and without the
>> new analysis, but all the benchmarks time out for me. I've sent him an
>> email to find out what I'm doing wrong -
On 30 September 2011 16:07, Max Bolingbroke wrote:
> I just tried to run David Peixotto's fibon suite with and without the
> new analysis, but all the benchmarks time out for me. I've sent him an
> email to find out what I'm doing wrong - if he can help me out then I
> should be able to post fulle
On 30 September 2011 11:55, David Terei wrote:
> Are you able to provide some performance numbers at this point? I'll
> have a play around with the code myself tomorrow but am very excited.
I can tell you that the example in my blog post gets 8.8% faster ;-)
I just tried to run David Peixotto's
On 30 September 2011 12:39, Max Bolingbroke wrote:
> On 30 September 2011 12:04, Simon Peyton-Jones wrote:
>> Why is this an *analysis*? Why can't we simply declare to LLVM that certain
>> things don't alias?
I forgot to mention that a custom alias analysis is also the approach
taken by Google
On 30 September 2011 12:04, Simon Peyton-Jones wrote:
> Why is this an *analysis*? Why can't we simply declare to LLVM that certain
> things don't alias?
We already do this to the extent possible - both the SpArg and the
HpArg are tagged with "noalias".
The problem is that this is only enough
VM?
Simon
| -Original Message-
| From: cvs-ghc-boun...@haskell.org [mailto:cvs-ghc-boun...@haskell.org] On
Behalf Of
| Max Bolingbroke
| Sent: 30 September 2011 09:54
| To: GHC Development Mailing List
| Subject: GHC-specific alias analysis for the LLVM backend
|
| Hi GHCers,
|
| As those of y
Great stuff!
Given the problems with dynamically linking in I wonder if it may be
worth while trying to get LLVM to include it? Probably not as it will
make it harder for us to tweak but an idea to consider.
Are you able to provide some performance numbers at this point? I'll
have a play around w
Hi GHCers,
As those of you who use the LLVM backend know, it often doesn't
optimise as aggressively as you would like. The reason for this is
often to do with aliasing. I've written a blog post outlining the
problem and a solution, in the form of a GHC-specific alias analyser
that tells LLVM that
16 matches
Mail list logo
