Thu Feb 25 20:51:05 PST 2010 b...@ouroborus.net
* Add DPH solution for 1st Euler problem
A ./tests/ghc-regress/dph/sumnats/
A ./tests/ghc-regress/dph/sumnats/Main.hs
A ./tests/ghc-regress/dph/sumnats/Makefile
A ./tests/ghc-regress/dph/sumnats/SumNatsVect.hs
A ./tests/ghc-reg
Thu Feb 25 19:36:07 PST 2010 b...@ouroborus.net
* Add missing Makefiles
A ./tests/ghc-regress/dph/dotp/Makefile
A ./tests/ghc-regress/dph/primespj/Makefile
View patch online:
http://darcs.haskell.org/testsuite/_darcs/patches/20100226033607-bf82d-105f4d259b13c2ebe0cf6b66e8d49aaa7b19b811
Thu Feb 25 18:00:34 PST 2010 b...@ouroborus.net
* Add DPH primes test
A ./tests/ghc-regress/dph/primespj/
A ./tests/ghc-regress/dph/primespj/Main.hs
A ./tests/ghc-regress/dph/primespj/PrimesVect.hs
A ./tests/ghc-regress/dph/primespj/dph-primespj.T
A ./tests/ghc-regress/dph/p
Thu Feb 25 18:56:30 PST 2010 b...@ouroborus.net
* Add DPH smvm test
A ./tests/ghc-regress/dph/smvm/
A ./tests/ghc-regress/dph/smvm/Main.hs
A ./tests/ghc-regress/dph/smvm/Makefile
A ./tests/ghc-regress/dph/smvm/SMVMVect.hs
A ./tests/ghc-regress/dph/smvm/dph-smvm.T
A ./tes
Thu Feb 25 17:47:00 PST 2010 b...@ouroborus.net
* In dph-dotp, compare with result computed via regular list fns.
M ./tests/ghc-regress/dph/dotp/Main.hs -3 +11
M ./tests/ghc-regress/dph/dotp/dph-dotp.T -1 +1
M ./tests/ghc-regress/dph/dotp/dph-dotp.stdout +1
View patch online:
http:
Thu Feb 25 17:36:38 PST 2010 b...@ouroborus.net
* Prefix dph tests with 'dph-' to avoid name conflicts
./tests/ghc-regress/dph/dotp/dotp.T ->
./tests/ghc-regress/dph/dotp/dph-dotp.T
./tests/ghc-regress/dph/dotp/dotp.stdout ->
./tests/ghc-regress/dph/dotp/dph-dotp.stdout
./tests
Wed Feb 24 20:26:34 PST 2010 b...@ouroborus.net
* Add DPH dotp test
A ./tests/ghc-regress/dph/dotp/
A ./tests/ghc-regress/dph/dotp/DotPVect.hs
A ./tests/ghc-regress/dph/dotp/Main.hs
A ./tests/ghc-regress/dph/dotp/dotp.T
A ./tests/ghc-regress/dph/dotp/dotp.stdout
View patch
Build description = STABLE on x86_64-unknown-linux
(cam-04-unx.europe.corp.microsoft.com)
Build location= /64playpen/simonmar/nightly/STABLE-cam-04-unx
Build config file = /home/simonmar/nightly/site/msrc/conf-STABLE-cam-04-unx
Nightly build started on cam-04-unx at Thu Feb 25 19:10:01 GMT 20
Build description = HEAD on x86_64-unknown-linux
(cam-04-unx.europe.corp.microsoft.com)
Build location= /64playpen/simonmar/nightly/HEAD-cam-04-unx
Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-04-unx
Nightly build started on cam-04-unx at Thu Feb 25 19:00:01 GMT 2010.
**
Build description = STABLE on i386-unknown-linux
(cam-02-unx.europe.corp.microsoft.com)
Build location= /playpen/simonmar/nightly/STABLE
Build config file = /home/simonmar/nightly/site/msrc/conf-STABLE-cam-02-unx
Nightly build started on cam-02-unx at Thu Feb 25 18:10:01 GMT 2010.
checki
Build description = HEAD on i386-unknown-linux
(cam-02-unx.europe.corp.microsoft.com)
Build location= /playpen/simonmar/nightly/HEAD
Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx
Nightly build started on cam-02-unx at Thu Feb 25 18:00:01 GMT 2010.
checking out
Wed Feb 24 02:14:34 PST 2010 Simon Marlow
* arith012, arith008: use -msse2 on i386 if available
M ./tests/ghc-regress/numeric/should_run/all.T -13 +10
View patch online:
http://darcs.haskell.org/testsuite/_darcs/patches/20100224101434-12142-f318978358b3de0c6c557c246b26d403a5f3c1a5.gz
___
Wed Feb 24 07:25:19 PST 2010 Simon Marlow
* Force encoding to UTF-8 when writing individual .conf files
M ./utils/ghc-pkg/Main.hs -14 +28
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20100224152519-12142-96a29065ed03209bb5925f9f1a200d43af5f9708.gz
__
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 09:14, Simon Peyton-Jones wrote:
|> good point. Could we call them 'tags-emacs' and 'tags-vim'?
|
| We could do, but tags and TAGS are the standard names.
|
| We could also have separate "make tags" and "make TAGS" commands, which
| generate only the named file.
|
| Whatever the d
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
+1 for having separate 'make tags' and 'make TAGS'.
Cheers,
Tris
On Thu, Feb 25, 2010 at 09:14:46AM +, Simon Peyton-Jones wrote:
> | > good point. Could we call them 'tags-emacs' and 'tags-vim'?
> |
> | We could do, but tags and TAGS are the standard names.
> |
> | We could also have sep
| > good point. Could we call them 'tags-emacs' and 'tags-vim'?
|
| We could do, but tags and TAGS are the standard names.
|
| We could also have separate "make tags" and "make TAGS" commands, which
| generate only the named file.
|
| Whatever the decision, implementing it will be easy.
|
Doe
24 matches
Mail list logo
