Don Stewart wrote:
Here's an example that doesn't use floating point:
import Data.Array.Vector
import Data.Bits
main = print . sumU $ zipWith3U (\x y z - x * y * z)
(enumFromToU 1 (1 :: Int))
(enumFromToU 2 (10001 :: Int))
(enumFromToU 7 (10008 :: Int))
In core:
main_$s$wfold
You could also have a look at the new 'Gold' linker that's part of
binutils. Not sure if this has been tested before with ghc but its
meant to have far greater performance (in time is what I've heard, not
sure about memory) then 'ld' and be a drop in replacement.
On 17 April 2010 00:00, Roman
Which branch are you working off though? ghc HEAD doesn't have the
latest changes to the new codegen, afaik the latest changes are in the
branch
http://darcs.haskell.org/ghc-cmm-03Sep10/
There is also a branch now though at
http://darcs.haskell.org/ghc-new-co-17Nov10/ which I'm not sure what
it
I haven't looked at these branches for a fair few weeks, the problem
when they fail to build usually is because all the libraries are just
set to follow HEAD, they're not actually branched themselves, just the
ghc compiler. So there are probably some patches from ghc HEAD that
need to be pulled in
On 10 January 2011 22:19, Simon Marlow marlo...@gmail.com wrote:
We're intrested in opinions from both active and potential GHC
developers/contributors. Let us know what you think - would this make life
harder or easier for you? Would it make you less likely or more likely to
contribute?
I
Hi Ian,
Could you merge my fix for this:
http://hackage.haskell.org/trac/ghc/ticket/4995
So patch is:
Wed Mar 9 13:53:46 PST 2011 David Terei davidte...@gmail.com
* LLVM: Fix #4995, llvm mangler broken for large compiles
Its a pretty small change and fixes an ugly issue with the LLVM
On 27 April 2011 20:01, Denys Rtveliashvili r...@mac.com wrote:
The lack of expected magic is in the assembler code:
---
addq $16,%r12
cmpq 144(%r13),%r12
ja .Lcz1
movl $1117,%ecx
movl $1113,%r10d
movl $,%r11d
movq 7(%rbx),%rax
cqto
I would suggest it be put under the Commentary/Compiler.
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler
Just add it as a top level bullet point for now, maybe after 'Wired-in
and known-key things'. Also you should update the Cmm language page:
I have a 16 core machine at work (with 48GB of ram, a perk of the job
:)). GHC can saturate them all. Can validate GHC in well under 10
minutes on it.
I also just got the 15 core i7 2.3GHz less then a week ago, it's a
very nice machine so I would recommend it. But yeah just getting the
2.2GHz is
On 7 November 2011 08:44, Simon Marlow marlo...@gmail.com wrote:
I think we should apply the minimal change to make all packages trusted by
default in 7.2.2. Any objections?
Agreed.
___
Glasgow-haskell-users mailing list
On 6 February 2012 06:09, Serge D. Mechveliani mech...@botik.ru wrote:
On Mon, Feb 06, 2012 at 02:33:53PM +0100, Karel Gardas wrote:
[..]
I would recommend to start here:
http://hackage.haskell.org/trac/ghc/wiki/Building/Unregisterised
Thank you.
Probably, there is something like an error
On 5 February 2012 10:48, Serge D. Mechveliani mech...@botik.ru wrote:
Dear GHC team,
I cannot understand why do you remove the C stage in GHC.
We didn't.
GHC itself can be built in two different ways, 'unregisterized' and
'registerized'. The former method is more portable while the latter
Thank you Simon for all the hard work on GHC over the years and for
the various opportunities I've had to work with you personally. The
change sounds exciting and I wish you all the best. With you there and
Bryan, hopefully Facebook can become a Haskell shop :). Also, perhaps
the change will mean
This is something I'd be happy to help out with.
On 30 November 2012 11:48, Johan Tibell johan.tib...@gmail.com wrote:
Hi Simon,
I will try to find some time to set up a automatic run of nofib on my
buildbot (which is powerful enough) and have it graph the results over
time (and perhaps even
I have always considered the LLVM code generator my responsibility and
will continue to do so. I don't seem to find the time to make
improvements to it but make sure to keep it bug free and working with
the latest LLVM releases. So if others want are interested in working
on it then there is
Right now there isn't really an overlap with LLVM passes. In general
the feeling of many of the GHC developers is that we don't want to
spend time duplicating what LLVM already does. That said, GHC is an
open source project so someone may be inclined to do so and there
isn't a lot of reason not to
Hi Nathan,
So dynamic libraries should be supported on a few platforms but not
all, not as many as the NCG. Support also varies from LLVM version.
What platform and version of LLVM are you trying to utilize? And
specifically what flags are you using?
Cheers,
David
On 11 December 2012 08:53,
I believe the testsuite now has support for inspecting assembly
output. Not sure if that would be best for your use case, but
something to consider.
On 14 December 2012 12:53, Johan Tibell johan.tib...@gmail.com wrote:
Hi,
I've been tracking down a few (unrelated) performance bugs related to
Hi Ian
This bug is still present in mainline. Any chance of it being fixed?
Cheers,
David
On 12 January 2013 06:38, Ian Lynagh i...@well-typed.com wrote:
Hi Sean,
On Mon, Dec 10, 2012 at 04:04:34PM +0100, Sean Leather wrote:
On Sun, Dec 9, 2012 at 10:39 PM, Ian Lynagh wrote:
Please test
Hi all,
Can people please file bugs about these issues when they are confirmed
to some degree? Lots of ARM LLVM stuff seems to just be floating
around mailing lists much higher chance of me or someone else
fixing if there are filed bug reports with test cases and/or patches
attached.
Austin
To pass to opt use '-optlo', e.g.,
$ ghc -fllvm -optlo-adce ...
Its documented in the GHC userguide.
Cheers,
David
On 26 January 2013 02:07, Nathan Hüsken nathan.hues...@posteo.de wrote:
On 01/26/2013 09:24 AM, Nathan Hüsken wrote:
On 01/25/2013 05:45 PM, Simon Marlow wrote:
On 25/01/13
I believe that some Microsoft Research folks at Cambridge got a fairly
far along implementation of Haskell on Java or .NET many years back
but concluded it wasn't a good fit. My rusty memory of a conversation
with Simon Marlow about this was that all the Java libraries basically
ended up in IO and
On 10 February 2013 13:02, Simon Peyton-Jones simo...@microsoft.com wrote:
What I am still missing is this:
| Mark is asking for major GHC releases every year at the most, preferably
| less frequently. That means major GHC releases in the sense that we do
| them now, where libraries
Hi Magicloud,
Setting build.mk to BuildFlavour = perf-llvm means that the GHC
built will be built using the LLVM backend of GHC.
For any build of GHC though, to *use* the LLVM backend of GHC you
simply want to compile with -fllvm.
The output of inplace/bin/ghc-stage2 �Cinfo won't differ for a
Nothing straight forward to do this. You could do any of:
1) Look at the output of make a GHC is compiled. Verify that by and
large most lines have '-fllvm' on them.
2) As above but pipe output of building GHC to a file. Grep it later
for '-fllvm', you should get a very high count.
3) Add a -v2
, etc.)
Cheers,
Karel
On 03/26/13 08:14 AM, David Terei wrote:
I don't believe so.
LLVM in head supports Arm64 so I imagine it wouldn't be too much work
to extend our existing Arm support (also through LLVM) to work with
Arm64. I'm not aware of any Arm64 hardware being available yet
This is great! It's nice to see something finer grain.
We'd of course like to bring Safe Haskell into the picture though! Our
concern with the new design as it stands is the OVERLAPS flag. We'd
prefer it to be eliminated in favor of requiring developers specify
both OVERLAPPABLE and OVERLAPS if
27 matches
Mail list logo
