On Nov 22, 2011, at 6:54 AM, Simon Marlow wrote:
> On 12/10/2011 11:26, Simon Marlow wrote:
>> On 11/10/2011 18:45, David Peixotto wrote:
>>> Ok, I have attached a set of patches to support building the GHC
>>> runtime with llvm-gcc. The patc
On Oct 22, 2011, at 5:43 PM, Johan Tibell wrote:
> On Sat, Oct 22, 2011 at 6:40 AM, David Peixotto wrote:
> Ok, so to do it the "quick" way would be to change the translation of the
> PopCnt primop in compiler/codeGen/CgPrimOp.hs? The change would be to first
>
end so I think
> the segfault you describe won't occur under the llvm test way.
>
> Cheers,
> David
>
> On 21 October 2011 16:23, Johan Tibell wrote:
>> Hi,
>>
>> On Fri, Oct 21, 2011 at 1:34 PM, David Peixotto wrote:
>>>
>>> I believ
After adding support for building GHC with llvm-gcc I had one new test
failure in validate. The failing test is cg071 which tests the popCnt
primitive function. The test is failing because a call to hs_popcnt8
is segfaulting.
The problem seems to be that the words passed to hs_popcnt8 are not
narr
The hooks for the optllvm way were there in the ghc config
file, but there was no entry in config.other_ways so that a
`make WAY=optllvm` would fail with an "unknown way" error
message.
This patch simply adds optllvm to the other_ways list.
0001-Add-optllvm-as-allowed-way-in-testsuite.patch
Des
You can also use the fibon benchmarks to measure compilation time
(https://github.com/dmpots/fibon). It will only collect per-benchmark compile
times unlike nofib so it would probably be useful as a performance measurement,
but not a way to pinpoint inefficiencies.
Since you are only interested
On Aug 16, 2011, at 5:05 PM, David Terei wrote:
> Anyway. I emailed the github people and got them to disable the error
> checking step on the cabal repo on github just a few days back, and so
> now the cabal repo is up to date and working fine. I'll email them now
> about the haddock repo and ask
I've attached a small patch that seems to fix the build. The problem was that
the `dtraceSparkCounters` function was getting called even when we were not
compiling for the threaded rts. The patch just moves the call inside the #ifdef
for the threaded rts.
The call had been placed outside the #i
If you run
$ ./sync-all --extra get
It will grab the parallel, deepseq, and stm packages for you.
On Jul 12, 2011, at 11:14 AM, Karel Gardas wrote:
> On 07/11/11 01:10 PM, Simon Marlow wrote:
>> On 11/07/2011 11:36, Karel Gardas wrote:
>>
Have you tried running some heavy -N2 tests? e.g.
The get command for the sync-all script was recently fixed with this commit
https://github.com/ghc/ghc/commit/aa39056860a47026b253469f56d623dc6a25e196#sync-all
If you forked before that commit you could possibly have a broken sync-all
script. You can fix it by setting up a remote for the origin
The first patch has a bug. I was adding the --bare flag at each clone, so we were getting lots of --bare flags towards the end of the list. This new patch only adds it once.
0001-Only-add-bare_flag-to-git-clone-args-if-non-empty.patch
Description: Binary data
On Jul 7, 2011, at 3:29 PM, David
Adding the bare_flag variable to the git args as an empty string was causingthe git clone command to fail with a complaint about too many arguments. Ithink it was directly calling execv with the empty string as a fourth argumentwhich caused git to complain. This patch only adds the flag as an argum
both
ways of accessing the gct.
On Jul 3, 2011, at 11:23 AM, David Peixotto wrote:
>
> On Jul 2, 2011, at 2:42 PM, Simon Marlow wrote:
>> On 02/07/11 19:34, David Peixotto wrote:
>>
>>> The best we could hope for would be for an access of `gct` to turn
>>> int
On Jul 2, 2011, at 2:42 PM, Simon Marlow wrote:
> On 02/07/11 19:34, David Peixotto wrote:
>
>> The best we could hope for would be for an access of `gct` to turn
>> into something like this in the GC:
> >
>> movq(%rdi),%rdi #deref the key which i
%+68.7%+67.8% +7.1%
Geometric Mean +0.0% +0.0%+30.7%+29.3% +0.7%
On Jul 1, 2011, at 2:45 PM, David Peixotto wrote:
>
> On Jul 1, 2011, at 2:05 PM, Simon Marlow wrote:
>
>> On 30/06/11 17:43, David Peixotto wrote:
>>> I have made the cha
On Jul 1, 2011, at 2:05 PM, Simon Marlow wrote:
> On 30/06/11 17:43, David Peixotto wrote:
>> I have made the changes necessary to compile GHC with llvm-gcc. The
>> major change was to use the pthread api for thread level storage to
>> access the gct variable during g
On Jul 1, 2011, at 10:10 AM, Dan Knapp wrote:
> Thank you for doing this work! I'm going to take some time over the
> weekend and integrate it into my own work on the build system.
Great!
> I'll fix/replace your autoconf patch to integrate with what I've already
> done - I did the work to pro
I think that the preprocessor is going to be a major impediment to getting GHC
compiling with clang. If we had a Haskell-specific preprocessor that would be a
big help, but it seems to me that it could be a lot of work to get it just
right.
Also, the preprocossor is use for cmm files which migh
Geometric Mean -76.3% +0.0% +5.4% +4.8% +0.1%
On Jun 27, 2011, at 6:18 PM, David Peixotto wrote:
> I'll take a look at getting the llvm-gcc route going by switching the gct
> variable to use pthread_getspecific() on mac os x. I can do some benchmarking
&g
On Jun 29, 2011, at 5:57 PM, Ian Lynagh wrote:
> On Tue, Jun 28, 2011 at 02:55:09PM -0500, David Peixotto wrote:
>>
>> Oddly, this commit does not seem to be in the github repo, even though the
>> commit date is 2007.
>
> Perhaps github has only recently started
Hmm, now I'm seeing a similar problem with the Cabal repo on github.
The last available commit in git://github.com/ghc/packages-Cabal.git is
31fce20bf6a0191e26e640d1c464deea00c8ac4d.
If I do a checkout from http://darcs.haskell.org/packages/Cabal.git I get up to
commit bc794b750d844b2b4716c6d25
t;>>>
>>>>>>>> This was using the 64bit version of GHC. I'll have a closer look.
>>>>>>>
>>>>>>> Perhaps that was when compiling StgCRun.c? It doesn't actually need
>>>>>>> register
I'm running into a problem getting a copy of ghc from github. I think perhaps
the haddock and binary repos are not properly synced. If I do
$ git clone git://github.com/ghc/ghc.git ghc-tmp
$ cd ghc
$ ./sync-all -r git://github.com/ghc get
I get the error
== running git clone gi
There was an extra % in the strftime string used in the fingerprintscript to name the output files. It worked fine in python 2.6 on macos, but was producing bad file names in python 2.7 on linux.
0001-Fix-strftime-string-in-fingerprint-script.patch
Description: Binary data
tories?
>
> On Mon, May 23, 2011 at 10:39 AM, David Peixotto wrote:
>
> On May 22, 2011, at 9:16 PM, Erik de Castro Lopo wrote:
>
> > Interesting tool. Do you have a set of these fingerprints dating back
> > a year or more?
>
> No, unfortunately I just wrote th
On May 22, 2011, at 9:16 PM, Erik de Castro Lopo wrote:
> Interesting tool. Do you have a set of these fingerprints dating back
> a year or more?
No, unfortunately I just wrote the script after the discussion in this thread.
I see it as a way to help in the future, but I don't think it will hel
On May 23, 2011, at 5:15 AM, Simon Marlow wrote:
> I merged in your branch. Thanks! Perhaps it would be a good idea to document
> the usage of the tool on
>
> http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources
Ok, I added some documentation there on why we need fingerprints an
I wrote a python script that can be used to record and reinstate the commit
state of all the git repositories used by GHC. It parses the output of the
sync-all log command suggested by Simon to create a "fingerprint" which is
just the pairs of (subdirectory, commit) that can be used to identify the
I found that the runtime stats output was incorrect for the one-line stats
(i.e. the +RTS -t -RTS output). The output was giving zeros for several of the
times, for example the mutator time. The problem was that the time values were
being computed inside a conditional so they were not correctly set
On Jan 10, 2011, at 5:19 AM, Simon Marlow 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?
+1 for mo
I am pleased to announce that I have finished porting the [fibon
benchmarks][1] into nofib. I added the benchmarks to a new subdirectory in the
nofib repository. The benchmarks are available as a single patch from this
temporary darcs repository:
http://www.cs.rice.edu/~dmp4866/darcs/nofib
Th
olds for the Repa package (that depends
> on the DPH library infrastructure).
>
> Ian, independent of the omission of DPH from the GHC 7.0.1 release, shouldn't
> the relevant packages not be on the branch?
>
> Manuel
>
> David Peixotto:
>> I'm trying to ge
I'm trying to get the dph libraries (primitive, vector, dph) using darcs-all in
the ghc-7.0 branch. It fails with this error:
darcs failed: Not a repository:
http://darcs.haskell.org/ghc-7.0/packages/primitive
What is the recommended way to get the dph packages from the 7.0 branch?
Here
is monomorphic, hence the error.
>
> Give it a type signature, or make it top-level. Either works fine.
>
> Simon
>
> From: cvs-ghc-boun...@haskell.org [mailto:cvs-ghc-boun...@haskell.org] On
> Behalf Of David Peixotto
> Sent: 16 September 2010 17:38
> To: cvs-ghc@
I'm now getting a type error when compiling with GHC HEAD that I wasn't getting
before (also GHC 6.10 and GHC 6.12 work fine). The code is part of a larger
program that I did not write and the type error is confusing to me. I cut it
down to the minimal I could, so hopefully it will be useful. Ca
I'm having a problem getting code with datatype contexts to build with GHC
HEAD. The code is from FGL, but even a simplified code like:
module Heap(
Heap(..)
) where
data Ord a => Heap a b = Empty | Node a b [Heap a b]
deriving Eq
does not work. I get the compile error:
Heap.hs:1:1:
Hi,
I created a patch that extends the PAPI support in the runtime to allow users
to collect native hardware events along with the preset PAPI events. The
extension was mostly to the parameter parsing as all the PAPI machinery was
already in place. The details are in
http://hackage.haskell.org
Hi Simon,
Thanks for the response. I have a few comments below.
On Mar 17, 2010, at 7:25 AM, Simon Marlow wrote:
> On 15/03/2010 18:35, David Peixotto wrote:
>> 1) Does it still make sense to pursue these optimizations in the native
>> code generator?
>
> Well, this transf
I have some questions after starting to look at implementing an optimization in
the GHC back end related to Trac ticket #1498[1,2]. The goal of the
optimization is to eliminate unnecessary heap checks in recursive functions.
For example, if we have a recursive function such as
f :: Int -> Int
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'
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
h wrote:
On Tue, Oct 27, 2009 at 06:20:55PM -0500, David Peixotto wrote:
If I try to configure on both HEAD and STABLE it bails out after
checking for gcc.
$ ./configure
...
checking for gcc... /usr/lib64/ccache/gcc
$
Looking at the config.log I see
$ cat config.log
...
configure:3634: /usr/lib64/
This seems to be causing some problems for me, though it's likely not
the root cause. I having trouble getting the configure step to work on
x86_64 linux with gcc 4.4.1.
If I try to configure on both HEAD and STABLE it bails out after
checking for gcc.
$ ./configure
...
checking for gcc...
Thanks for the input. I'll take a look at the nobench suite. I might
be interested in working to improve nobench. Is there some obvious
improvements that people have in mind (besides using Criterion), or it
just generally needs some updated benchmarks? I suppose one question
to consider is
Hi,
I'm interested in looking at the effects on performance of various
compiler optimizations in GHC. I ran the nofib benchmarks against the
stable branch to get a feel for some very simple results. In my
measurements I only saw a maximum of 2.8% difference in runtime when
using -O0 and -
45 matches
Mail list logo
