Re: How to use C-land variable from Cmm-land?
On 10/12/12 12:46, Yuras Shumovich wrote:
On Mon, 2012-12-10 at 10:58 +, Simon Marlow wrote:
On 08/12/12 23:12, Yuras Shumovich wrote:
I tried to hack stg_putMVarzh directly:
if (enabled_capabilities == 1) {
info = GET_INFO(mvar);
} else {
(ptr info) = ccall lockClosure(mvar ptr);
}
You should use n_capabilities, not enabled_capabilities. The latter
might be 1, even when there are multiple capabilities actually in use,
while the RTS is in the process of migrating threads.
Could you please elaborate? setNumCapabilities is guarded with
asquireAllCapabilities, so all threads are in scheduler. And threads
will be migrated from disabled capabilities before they get a chance to
put/take mvar.
I changed my mind re enabled_capabilities/n_capabilities a number of
times during the weekend. Most likely you are right, and I should use
n_capabilities. But I'll appreciate if you find time to explain it for
me.
n_capabilities is the actual number of capabilities, and can only
increase, never decrease. enabled_capabilities is the number of
capabilities we are currently aiming to use, which might be less than
n_capabilities. If enabled_capabilities is less than n_capabilities,
there might still be activity on the other capabilities, but the idea is
that threads get migrated away from the inactive capabilities as quickly
as possible. It's hard to do this immediately, which is why we have
enabled_capabilities and we don't just change n_capabilities.
The problem was that movl $enabled_capabilities,%eax loaded the
address of enabled_capabilities, not a value.
Yes, sorry, you are right.
(Again, why does it use
32bit register? The value is 32bit on linux, but the address is 64bit,
isn't it?) So the correct way to use C-land variable is:
if (CInt[enabled_capabilities]) {...}
Not very intuitive, but at least it works.
That's C-- syntax for a memory load of a CInt value (CInt is a CPP
symbol that expands to a real C-- type, like bits32). Unlike in C,
memory loads are explicit in C--.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi + FFI + global C variables
On 10/12/12 00:11, Nils wrote:
I'm currently working with a C library that needs to use/modify global C
variables, for example:
igraph_bool_t igraphhaskell_initialized = 0;
int igraphhaskell_initialize()
{
if (igraphhaskell_initialized != 0)
{
printf(C: Not initializing. igraphhaskell_initialized = %i\n,
igraphhaskell_initialized);
return 1;
}
// initialization
}
If I compile an example programm using this library everything works
fine, but if I try to run the same program in GHCi it dies with the message
C: Not initializing. igraphhaskell_initialized = -90
The value (and apparently the adress of the global variable) is
completly off, and I have no idea what is causing this or how to solve
this issue and make the library GHCi-friendly. Is it possible to run
this code in GHCi at all? Also, since it's a foreign library I obviously
cannot just change the C code to simply not use any global variables at
all.
Sounds like it could be this: http://hackage.haskell.org/trac/ghc/ticket/781
Compiling your program with -fPIC should fix it.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Mailing list reorganisation
Hi all, Following a recent discussion, we propose to reorganise the GHC-related mailing lists so that we end up with: glasgow-haskell-users For user discussions ghc-devs For developer discussions ghc-commits For automated commit messages from the git repositories ghc-builds For automated nightly build reports ghc-tickets For automated messages from trac We would remove cvs-ghc cvs-libraries cvs-other glasgow-haskell-bugs but leave the archives in place, and for now forwarding messages to cvs-* to ghc-devs, and glasgow-haskell-bugs to ghc-tickets. (cvs-libraries and cvs-other are included in this list, because we think they are mainly used by libraries that GHC HQ maintains, or by GHC's lagging repos of libraries that other people maintain). The initial subscriber lists for ghc-devs, ghc-commits and ghc-builds would be the union of the subscribers of cvs-ghc, cvs-libraries and cvs-other. For ghc-tickets it would be the subscriber list for glasgow-haskell-bugs. Does that sound reasonable? Does anyone have any further questions or comments? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Mailing list reorganisation
On Tue, Dec 11, 2012 at 7:04 AM, Ian Lynagh i...@well-typed.com wrote: Does that sound reasonable? Does anyone have any further questions or comments? Sound good to me. Thanks for working on this. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] GHCi + FFI + global C variables
On Tue, Dec 11, 2012 at 5:57 AM, Francisco Vieira de Souza vieira.u...@gmail.com wrote: Hi Simon! Is it not necessary to show the type of igraph_bool_t igraphhaskell_initialized like int igraph_bool_t igraphhaskell_initialized = 0? igraph_bool_t uses the _t suffix convention for typedefs in C; in other words, it *is* the type. (And if it weren't, that would be a compile time error, not link time.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Haskell Dynamic Loading with -fllvm
Essentially I have a use case that, if worked, would save countless hours in development time. I am writing a scientific computing web service utilizing the Repa and Snap libraries. The Snap framework has a dynamic loader that will load modules on the fly when the source files change. This works excellent! The problem is that the modules must be compiled with full optimizations (including -fllvm) or web service operations take minutes instead of second to execute at run time. I do not mind the penalty paid for optimized compilation. It is still much faster than recompiling and linking the entire exe from scratch and restarting the server. The problem is when the code is compiled with -fllvm dynamically, it crashes. I believe this is a known issue as listed in this trac - http://hackage.haskell.org/trac/ghc/ticket/4210 NOTE: it says The LLVM backend doesn't support dynamic libraries at the moment. My question is could anyone point me in the right direction as to what might need to be implemented support for this? Is anyone currently working on it? It would be a huge win for the work I am currently doing, to the point where if I can't find a way to get this working (even if it means diving in and attacking it myself), I may have to switch to another language/platform. Thanks, Nathan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Hoopl vs LLVM?
| In my opinion we should only implement optimizations in Hoopl that
| LLVM cannot do due to lack high-level information that we might have
| gotten rid of before we reach the LLVM code generator*. I don't think
Indeed. And I think there is probably quite a lot that is in reach for C--,
but out of reach for LLVM. Why? Because before we pass the code to LLVM we do
CPS-conversion. So code that started like this:
f() {
x = blah
z = blah2
p,q = g(x)
res = z + p - q
return res
}
Turns into something more like this:
f () {
x = blah
z = blah2
...push z on stack...
...push fr1 onto stack...
jump g(x)
}
fr1( p,q ) {
z = ...pop from stack...
res = z + p - q
return res
}
Notice that the stack is now *explicit* rather than implicit, and LLVM has no
hope of moving the assignment to z past the call to g (which is trivial in the
original). I can explain WHY we do this (there is stuff on the wiki) but the
fact is that we do, and it's no accident.
Some transformations and optimisations are only possible before the CPS
conversion, which means LLVM can't do it. There is real meat here.
Moreover, one of Simon M's last acts was to switch to the new codgen path,
which uses the new C-- rep etc. That leaves us *ready* to do some
traditional-style optimisations on C--, but we have not *actually done* so.
The field is wide open.
For example, I had a masters student three years ago (Marcej Wos) who implement
the classic tail-call-becomes-loop optimisation, and got a surprisingly large
benefit. His code is rotted now, but I must dig out his Masters project report
which described it all rather well.
In short, go for it. But as Johan says, concentrate on things that LLVM can't
get.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Johan Tibell
| Sent: 10 December 2012 22:40
| To: Greg Fitzgerald
| Cc: GHC Users Mailing List
| Subject: Re: Hoopl vs LLVM?
|
| On Mon, Dec 10, 2012 at 2:24 PM, Greg Fitzgerald gari...@gmail.com wrote:
| Should one group be stealing ideas from the other? Or apples and oranges?
|
| In my opinion we should only implement optimizations in Hoopl that
| LLVM cannot do due to lack high-level information that we might have
| gotten rid of before we reach the LLVM code generator*. I don't think
| we should spend time re-implementing LLVM passes in Hoopl. We have
| limited time on our hands (much less than the LLVM team) and we're
| unlikely to do a better job than them here, as we're talking about
| implementing standard, imperative code optimization. I think our time
| is better spent on 1) making sure we pass enough information to LLVM
| for it to do a good job and 2) working on higher-level optimizations
| (e.g. Core-to-Core).
|
| * This also means that I think we should try to preserve any
| information LLVM might need all the way down to the code generator.
|
| -- Johan
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Hoopl vs LLVM?
Cool info!
Would love to see that report if you can dig it up :)
-Carter
On Tue, Dec 11, 2012 at 2:16 PM, Simon Peyton-Jones
simo...@microsoft.comwrote:
| In my opinion we should only implement optimizations in Hoopl that
| LLVM cannot do due to lack high-level information that we might have
| gotten rid of before we reach the LLVM code generator*. I don't think
Indeed. And I think there is probably quite a lot that is in reach for
C--, but out of reach for LLVM. Why? Because before we pass the code to
LLVM we do CPS-conversion. So code that started like this:
f() {
x = blah
z = blah2
p,q = g(x)
res = z + p - q
return res
}
Turns into something more like this:
f () {
x = blah
z = blah2
...push z on stack...
...push fr1 onto stack...
jump g(x)
}
fr1( p,q ) {
z = ...pop from stack...
res = z + p - q
return res
}
Notice that the stack is now *explicit* rather than implicit, and LLVM has
no hope of moving the assignment to z past the call to g (which is trivial
in the original). I can explain WHY we do this (there is stuff on the
wiki) but the fact is that we do, and it's no accident.
Some transformations and optimisations are only possible before the CPS
conversion, which means LLVM can't do it. There is real meat here.
Moreover, one of Simon M's last acts was to switch to the new codgen
path, which uses the new C-- rep etc. That leaves us *ready* to do some
traditional-style optimisations on C--, but we have not *actually done* so.
The field is wide open.
For example, I had a masters student three years ago (Marcej Wos) who
implement the classic tail-call-becomes-loop optimisation, and got a
surprisingly large benefit. His code is rotted now, but I must dig out his
Masters project report which described it all rather well.
In short, go for it. But as Johan says, concentrate on things that LLVM
can't get.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:
glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Johan Tibell
| Sent: 10 December 2012 22:40
| To: Greg Fitzgerald
| Cc: GHC Users Mailing List
| Subject: Re: Hoopl vs LLVM?
|
| On Mon, Dec 10, 2012 at 2:24 PM, Greg Fitzgerald gari...@gmail.com
wrote:
| Should one group be stealing ideas from the other? Or apples and
oranges?
|
| In my opinion we should only implement optimizations in Hoopl that
| LLVM cannot do due to lack high-level information that we might have
| gotten rid of before we reach the LLVM code generator*. I don't think
| we should spend time re-implementing LLVM passes in Hoopl. We have
| limited time on our hands (much less than the LLVM team) and we're
| unlikely to do a better job than them here, as we're talking about
| implementing standard, imperative code optimization. I think our time
| is better spent on 1) making sure we pass enough information to LLVM
| for it to do a good job and 2) working on higher-level optimizations
| (e.g. Core-to-Core).
|
| * This also means that I think we should try to preserve any
| information LLVM might need all the way down to the code generator.
|
| -- Johan
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Cvs-ghc mailing list
cvs-...@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Hoopl vs LLVM?
On Tue, Dec 11, 2012 at 11:16 AM, Simon Peyton-Jones simo...@microsoft.com wrote: Notice that the stack is now *explicit* rather than implicit, and LLVM has no hope of moving the assignment to z past the call to g (which is trivial in the original). I can explain WHY we do this (there is stuff on the wiki) but the fact is that we do, and it's no accident. I'd definitely be interesting in understanding why as it, like you say, makes it harder for LLVM to understand what our code does and optimize it well. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Hoopl vs LLVM?
Thank you all for your replies. On Tue, Dec 11, 2012 at 11:16 AM, Simon Peyton-Jones simo...@microsoft.comwrote: And I think there is probably quite a lot that is in reach for C--, but out of reach for LLVM. Why? Because before we pass the code to LLVM we do CPS-conversion. Is there a case for making a C/C++ compiler target C-- instead of LLVM? Or does its optimizations cater more to functional programming or lazy evaluation? Thanks, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-7.6.2 breaks haddock interface...
Hi,
I built GHC 7.6.2-rc1 for Debian. Unfortunately, we have this:
Control files of package ghc-haddock: lines which differ (wdiff format)
---
Depends: ghc (= [-7.6.1-3),-] {+7.6.1.20121207-1),+} libc6 (= 2.11), libffi5
(= 3.0.4), libgmp10
Installed-Size: [-32917-] {+33044+}
Provides: haddock, [-haddock-interface-21-] {+haddock-interface-22+}
Version: [-7.6.1-3-] {+7.6.1.20121207-1+}
i.e. upstream has bumped the haddock interface number. I really was not
expecting this from a minor release.
@GHC devs: Is that intentional? I.e., is there really a change to the
on-disk format of the .haddock files? Can we expect this to be stable
until 7.6.2 final?
In general, please only bump the interface number if really required,
makes live much easier for us (and probably also for some of your other
users).
@Debian: If the answer is yes, what should we do? I think I have
automated rebuilding everything (at least everything in Darcs) enough to
make that not as painful as it used to be, but it would still take some
time. On the other hand, it would break Haskell in experimental for some
time (maybe a week, optimistically). But then, it is already partly
broken.
Thanks,
Joachim
--
Joachim nomeata Breitner
Debian Developer
nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata
signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-7.6.2 breaks haddock interface...
Hi Joachim,
On Wed, Dec 12, 2012 at 12:20:35AM +0100, Joachim Breitner wrote:
I built GHC 7.6.2-rc1 for Debian.
Thanks for testing!
Provides: haddock, [-haddock-interface-21-] {+haddock-interface-22+}
i.e. upstream has bumped the haddock interface number. I really was not
expecting this from a minor release.
@GHC devs: Is that intentional?
CCing the haddock dev list.
I.e., is there really a change to the
on-disk format of the .haddock files? Can we expect this to be stable
until 7.6.2 final?
In general, please only bump the interface number if really required,
makes live much easier for us (and probably also for some of your other
users).
@Debian: If the answer is yes, what should we do? I think I have
automated rebuilding everything (at least everything in Darcs) enough to
make that not as painful as it used to be, but it would still take some
time. On the other hand, it would break Haskell in experimental for some
time (maybe a week, optimistically). But then, it is already partly
broken.
Won't you have to rebuild everything anyway, due to the GHC version
number in the .hi files changing?
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Mailing list reorganisation
Good plan! Ian Lynagh i...@well-typed.com: Hi all, Following a recent discussion, we propose to reorganise the GHC-related mailing lists so that we end up with: glasgow-haskell-users For user discussions ghc-devs For developer discussions ghc-commits For automated commit messages from the git repositories ghc-builds For automated nightly build reports ghc-tickets For automated messages from trac We would remove cvs-ghc cvs-libraries cvs-other glasgow-haskell-bugs but leave the archives in place, and for now forwarding messages to cvs-* to ghc-devs, and glasgow-haskell-bugs to ghc-tickets. (cvs-libraries and cvs-other are included in this list, because we think they are mainly used by libraries that GHC HQ maintains, or by GHC's lagging repos of libraries that other people maintain). The initial subscriber lists for ghc-devs, ghc-commits and ghc-builds would be the union of the subscribers of cvs-ghc, cvs-libraries and cvs-other. For ghc-tickets it would be the subscriber list for glasgow-haskell-bugs. Does that sound reasonable? Does anyone have any further questions or comments? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
