Harendra Kumar writes:
> On 19 June 2016 at 14:03, Ben Gamari wrote:
>
>>
>> Indeed it would be great if you could provide the program that produced
>> this code.
>>
>> >> It would be great to open Trac tickets to track some of the optimization
>
>
> Ok, I created an account on ghc trac and rais
On 19 June 2016 at 14:03, Ben Gamari wrote:
>
> Indeed it would be great if you could provide the program that produced
> this code.
>
> >> It would be great to open Trac tickets to track some of the optimization
Ok, I created an account on ghc trac and raised two tickets: #12231 &
#12232. Yay!
Agreed. There's also some other mismatches between ghc and llvm in a few
fun / interesting ways!
There's a lot of room for improvement in both code gens, but there's also a
lot of room to improve the ease of experimenting with improvements. Eg we
don't have a peephole pass per target, so those
Harendra Kumar writes:
> Thanks Ben! I have my responses inline below.
>
No worries!
> On 16 June 2016 at 18:07, Ben Gamari wrote:
>
>> For the record, I have also struggled with register spilling issues in
>> the past. See, for instance, #10012, which describes a behavior which
>> arises from
On Sun, Jun 19, 2016 at 12:30 AM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:
> This email would have been marked spam had I not unmarked all your emails
> as spam. Also a gmail user :/
Same. I forwarded my received headers to the infra folks; they made some
more adjustments to Mailma
enobu Tani [mailto:takenobu...@gmail.com
> ]
> *Sent:* 18 June 2016 08:18
> *To:* Simon Peyton Jones >
> *Subject:* Re: CMM-to-ASM: Register allocation wierdness
>
>
>
> Hi Simon,
>
>
>
> I report to you about your mails.
>
>
>
> Maybe, your mail
; *From:* Takenobu Tani [mailto:takenobu...@gmail.com]
> *Sent:* 18 June 2016 08:18
> *To:* Simon Peyton Jones
> *Subject:* Re: CMM-to-ASM: Register allocation wierdness
>
>
>
> Hi Simon,
>
>
>
> I report to you about your mails.
>
>
>
> Maybe, your mai
, could you let me know?
Thanks
Simon
From: Takenobu Tani [mailto:takenobu...@gmail.com]
Sent: 18 June 2016 08:18
To: Simon Peyton Jones
Subject: Re: CMM-to-ASM: Register allocation wierdness
Hi Simon,
I report to you about your mails.
Maybe, your mails don't reach to Gmail users.
I don'
Thanks Ben! I have my responses inline below.
On 16 June 2016 at 18:07, Ben Gamari wrote:
>
> Indeed; I've opened D2335 [1] to reenable -fregs-graph and add an
> appropriate note to the users guide.
>
Thanks! That was quick.
> For the record, I have also struggled with register spilling issue
Ccing David Spitzenberg, who has thought about proc-point splitting, which
is relevant for reasons that we will see below.
Harendra Kumar writes:
> On 16 June 2016 at 13:59, Ben Gamari wrote:
>>
>> It actually came to my attention while researching this that the
>> -fregs-graph flag is curren
| All-in-all, the graph coloring allocator is in great need of some love;
| Harendra, perhaps you'd like to have a try at dusting it off and perhaps
| look into why it regresses in compiler performance? It would be great if
| we could use it by default.
I second this. Volunteers are sorely neede
That's a nice read, thanks for the pointer. I agree with the solution
presented there. If we can do that it will be awesome. If help is needed I
can spend some time on it.
One of the things that I noticed is that the code can be optimized
significantly if we know the common case so that we can opt
On 06/16/16 12:53 PM, Harendra Kumar wrote:
A thought that came to my mind was whether we should focus on getting
better code out of the llvm backend or the native code generator. LLVM
seems pretty good at the specialized task of code generation and low
level optimization, it is well funded, wide
On 16 June 2016 at 13:59, Ben Gamari wrote:
>
> It actually came to my attention while researching this that the
> -fregs-graph flag is currently silently ignored [2]. Unfortunately this
> means you'll need to build a new compiler if you want to try using it.
Yes I did try -fregs-graph and -fregs
Harendra Kumar writes:
> My earlier experiment was on GHC-7.10.3. I repeated this on GHC-8.0.1 and
> the assembly traced was exactly the same except for a marginal improvement.
> The 8.0.1 code generator removed the r14/r11 swap but the rest of the
> register ring shift remains the same. I have u
> Hi, I am implementing unicode normalization in Haskell. I
> challenged myself to match the performance with the best C/C++
> implementation, the best being the ICU library. I am almost there,
> beating it in one of the benchmarks and within 30% for others. I am
> out of all application level tri
My earlier experiment was on GHC-7.10.3. I repeated this on GHC-8.0.1 and
the assembly traced was exactly the same except for a marginal improvement.
The 8.0.1 code generator removed the r14/r11 swap but the rest of the
register ring shift remains the same. I have updated the github gist with
the 8
Hi,
I am implementing unicode normalization in Haskell. I challenged myself to
match the performance with the best C/C++ implementation, the best being
the ICU library. I am almost there, beating it in one of the benchmarks and
within 30% for others. I am out of all application level tricks that I
18 matches
Mail list logo