RE: Hoopl question
Also Ning Wang and Andreas Voellmy have taken over maintainership of Hoopl, so they would be good people to talk to. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Michal Terepeta Sent: 02 May 2015 14:21 To: ghc-devs@haskell.org Subject: Hoopl question Hi, I've just read through the Hoopl paper and then noticed https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance which is really interesting. But it seems that there were no updates to the page in like 3 years, yet the new codegen seems to be using Hoopl... Does anyone know what is the current status of this? Thanks, Michal ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Hoopl question
Also Ning Wang and Andreas Voellmy have taken over maintainership of Hoopl Sadly, this is not what Hackage says. Janek , so they would be good people to talk to. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Michal Terepeta Sent: 02 May 2015 14:21 To: ghc-devs@haskell.org Subject: Hoopl question Hi, I've just read through the Hoopl paper and then noticed https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance which is really interesting. But it seems that there were no updates to the page in like 3 years, yet the new codegen seems to be using Hoopl... Does anyone know what is the current status of this? Thanks, Michal --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Hoopl question
well perhaps they have not yet uploaded a new version. But I believe it's as agreed with all parties. Simon | -Original Message- | From: Jan Stolarek [mailto:jan.stola...@p.lodz.pl] | Sent: 05 May 2015 12:04 | To: ghc-devs@haskell.org | Cc: Simon Peyton Jones; Michal Terepeta; Ning Wang | Subject: Re: Hoopl question | | Also Ning Wang and Andreas Voellmy have taken over maintainership of | Hoopl | Sadly, this is not what Hackage says. | | Janek | | , | so they would be good people to talk to. | | Simon | | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Michal Terepeta Sent: 02 May 2015 14:21 | To: ghc-devs@haskell.org | Subject: Hoopl question | | Hi, | | I've just read through the Hoopl paper and then noticed | | https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerform | ance which is really interesting. But it seems that there were no | updates to the page in like 3 years, yet the new codegen seems to be | using Hoopl... Does anyone know what is the current status of this? | | Thanks, | Michal | | | | --- | Politechnika Łódzka | Lodz University of Technology | | Treść tej wiadomości zawiera informacje przeznaczone tylko dla | adresata. | Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez | pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej | usunięcie. | | This email contains information intended solely for the use of the | individual to whom it is addressed. | If you are not the intended recipient or if you have received this | message in error, please notify the sender and delete it from your | system. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Hoopl question
On Sun, May 3, 2015 at 7:39 PM Jan Stolarek jan.stola...@p.lodz.pl wrote: Michał, one of my students is currently working on this: https://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup as his BSc thesis (see #8315). It might turn out that he will also have enough time to focus on performance issues in Hoopl but at this point it is hard to tell. Janek Sounds great! :-) Which reminds me about another question I had -- the main reason to have the specialized module in GHC (instead of relying on the Hoopl one) is performance, right? (as in, the module is specialized for the UniqSM, but otherwise pretty close to Hoopl.Dataflow?) Thanks, Michal ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Hoopl question
Which reminds me about another question I had -- the main reason to have the specialized module in GHC (instead of relying on the Hoopl one) is performance, right? Yes. If you're interested you might look at ghc-devs archives from July and August 2013 - I was doing MSR internship at that time and I had some questions about Hoopl. You might find these helpful or interesting (well, answers, not questions :-) ). Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Hoopl question
Michał, one of my students is currently working on this: https://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup as his BSc thesis (see #8315). It might turn out that he will also have enough time to focus on performance issues in Hoopl but at this point it is hard to tell. Janek Dnia sobota, 2 maja 2015, Michal Terepeta napisał: Hi, I've just read through the Hoopl paper and then noticed https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance which is really interesting. But it seems that there were no updates to the page in like 3 years, yet the new codegen seems to be using Hoopl... Does anyone know what is the current status of this? Thanks, Michal --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Hoopl question
Hi, I've just read through the Hoopl paper and then noticed https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance which is really interesting. But it seems that there were no updates to the page in like 3 years, yet the new codegen seems to be using Hoopl... Does anyone know what is the current status of this? Thanks, Michal ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Yet Another Hoopl Question
One possibility is to do this transformation once and for all, *before* the constant-prop pass, since it is not dependent on the facts generated by the pass. Yes, that was Geoffrey's suggestion as well. I'll do that once I fix some remaining issues in copy propagation. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Yet Another Hoopl Question
| So why are Hoopl's rewrite functions specialized to UniqSM monad? My | understanding so far was that this is precisely because we need access to Uniq | supply to generate new labels and registers during rewriting. I'm guessing that | nobody intended that these newly generated things will be added as facts? Correct. | complicated_expr, I rewrite a store to a stack location with | |newReg1 = complicated_expr |I32[(old + 4)] = newReg1 Yes, as Simon says, you need a deterministic name for newReg1. An obvious choice would be reg_L3_7 if this was the 7th instruction of a block whose label was L3. Then the register name would be unaffected by any other rewrites, in any other block, or earlier in this block. But that's not altogether easy, since LocalRegs are identified by a Unique, not a string. One possibility is to do this transformation once and for all, *before* the constant-prop pass, since it is not dependent on the facts generated by the pass. Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Yet Another Hoopl Question
I have yet another Hoopl question. One of my rewrites allocates a new unique
local register and this register is later added as a fact. So I have Cmm code
that looks like this:
I32[(old + 4)] = complicated_expr
which is rewritten to:
newReg1 = complicated_expr
I32[(old + 4)] = newReg1
and then I add { I32[(old + 4)] = newReg1 } as a fact. When Hoopl reaches end
of the iteration it realizes it has learned some new facts, so it keeps the
facts (including fact about a new unique register) and discards rewritten graph
(including said new register). In the next iteration it performs the rewrite
again, allocating a different new register and adding fact about this different
register. At the end of this iteration same thing happens again: facts are
kept, rewrite is discarded. And so my code falls into an infinite loop, because
every time I'm allocating a different register and every time hoopl thinks it
learned sth new and discards the rewritten graph. How can I perform this
rewrite and avoid falling into a loop?
Janek
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Yet Another Hoopl Question
On 13/08/13 13:03, Jan Stolarek wrote:
I have yet another Hoopl question. One of my rewrites allocates a new unique
local register and this register is later added as a fact. So I have Cmm code
that looks like this:
I32[(old + 4)] = complicated_expr
which is rewritten to:
newReg1 = complicated_expr
I32[(old + 4)] = newReg1
and then I add { I32[(old + 4)] = newReg1 } as a fact. When Hoopl reaches end
of the iteration it realizes it has learned some new facts, so it keeps the
facts (including fact about a new unique register) and discards rewritten graph
(including said new register). In the next iteration it performs the rewrite
again, allocating a different new register and adding fact about this different
register. At the end of this iteration same thing happens again: facts are
kept, rewrite is discarded. And so my code falls into an infinite loop, because
every time I'm allocating a different register and every time hoopl thinks it
learned sth new and discards the rewritten graph. How can I perform this
rewrite and avoid falling into a loop?
Your transfer function is not monotonic, because each time you apply it
it gives a different result.
The next question is well how do I do this then?. I'm not quite sure,
maybe you need to use a deterministic name supply monad.
Cheers,
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Yet Another Hoopl Question
Forgive me for asking the classic question: What are you really trying to do?
Edward
Excerpts from Simon Marlow's message of Tue Aug 13 09:25:51 -0400 2013:
On 13/08/13 13:03, Jan Stolarek wrote:
I have yet another Hoopl question. One of my rewrites allocates a new
unique local register and this register is later added as a fact. So I have
Cmm code that looks like this:
I32[(old + 4)] = complicated_expr
which is rewritten to:
newReg1 = complicated_expr
I32[(old + 4)] = newReg1
and then I add { I32[(old + 4)] = newReg1 } as a fact. When Hoopl reaches
end of the iteration it realizes it has learned some new facts, so it keeps
the facts (including fact about a new unique register) and discards
rewritten graph (including said new register). In the next iteration it
performs the rewrite again, allocating a different new register and adding
fact about this different register. At the end of this iteration same thing
happens again: facts are kept, rewrite is discarded. And so my code falls
into an infinite loop, because every time I'm allocating a different
register and every time hoopl thinks it learned sth new and discards the
rewritten graph. How can I perform this rewrite and avoid falling into a
loop?
Your transfer function is not monotonic, because each time you apply it
it gives a different result.
The next question is well how do I do this then?. I'm not quite sure,
maybe you need to use a deterministic name supply monad.
Cheers,
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Yet Another Hoopl Question
The next question is well how do I do this then?. I'm not quite sure, maybe you need to use a deterministic name supply monad. So why are Hoopl's rewrite functions specialized to UniqSM monad? My understanding so far was that this is precisely because we need access to Uniq supply to generate new labels and registers during rewriting. I'm guessing that nobody intended that these newly generated things will be added as facts? Forgive me for asking the classic question: What are you really trying to do? I'm doing copy (constant) propagation and one of my intentions is to minimize traffic to/from the stack when possible. Since I cannot propagate complicated_expr, I rewrite a store to a stack location with newReg1 = complicated_expr I32[(old + 4)] = newReg1 By recording second assignment as a fact it is now possible to replace references to I32[(old + 4)] with references to newReg1, which will effectively make I32[(old + 4)] = newReg1 assignment dead. So now information will be kept in registers instead of the stack. Of course it is still possible that there will be not enough registers and we'll have to spill some things to the stack. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
