GHC Weekly News - 10/24/2014

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

GHC Weekly News - 10/24/2014

Austin Seipp-5
Note: this post is available (with full hyperlinks) at
https://ghc.haskell.org/trac/ghc/blog/weekly20141024

---------

Hi *,

Welcome to the weekly GHC news. This one will be short this week, as
the preceding one occurred only on Monday - but we'll be going with
Fridays from now on, so next week we'll hopefully see a longer list.

 - GHC 7.8.4 tickets have been in waiting, and the RC will be soon
after Austin finishes some final merges and tests on his branch. **We
have not committed a time for the release after the RC**, yet we would
like people to **please seriously test** and immediately report any
major showstoppers - or alert us of ones we missed.
 - For the GHC 7.10 release, one of the major features we planned to
try and merge was DWARF debugging information. This is actually a
small component of larger ongoing work, including adding stack traces
to Haskell executables. While, unfortunately, not all the work can be
merged, we talked with Peter, and made a plan: our hope is to get
Phab:D169 merged, which lays all the groundwork, followed by DWARF
debugging information in the code generators. This will allow tools
like `gdb` or other extensible debuggers to analyze C-- IR accurately
for compiled executables.
 Peter has written up a wiki page, available at SourceNotes,
describing the design. We hope to land all the core infrastructure in
Phab:D169 soon, followed by DWARF information for the Native Code
Generator, all for 7.10.1
 - This past week, a discussion sort of organically started on the
`#ghc` IRC channel about the future of the LLVM backend. GHC's backend
is buggy, has no control over LLVM versions, and breaks frequently
with new versions. This all significantly impacts users, and relegates
the backend to a second class citizen. After some discussion, Austin
wrote up a proposal for a improved backend, and wrangled several other
people to help. The current plan is to try an execute this by GHC
7.12, with the goal of making the LLVM backend Tier 1 for major
supported platforms.
 - You may notice https://ghc.haskell.org is now responds slightly
faster in some cases - we've activated a caching layer (CloudFlare) on
the site, so hopefully things should be a little more smooth.

Closed tickets this week: #9684, #9692, #9038, #9679, #9537, #1473.

--
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

Reply | Threaded
Open this post in threaded view
|

GHC Weekly News - 10/24/2014

Luite Stegeman
>
>
>  - For the GHC 7.10 release, one of the major features we planned to
> try and merge was DWARF debugging information. This is actually a
> small component of larger ongoing work, including adding stack traces
> to Haskell executables. While, unfortunately, not all the work can be
> merged, we talked with Peter, and made a plan: our hope is to get
> Phab:D169 merged, which lays all the groundwork, followed by DWARF
> debugging information in the code generators. This will allow tools
> like `gdb` or other extensible debuggers to analyze C-- IR accurately
> for compiled executables.
>  Peter has written up a wiki page, available at SourceNotes,
> describing the design. We hope to land all the core infrastructure in
> Phab:D169 soon, followed by DWARF information for the Native Code
> Generator, all for 7.10.1
>

I'm currently working on some internal changes in GHCJS to prepare for GHC
7.10, support source maps [1] and make the optimizer more effective and
reliable (smaller/faster code!). So this change, retaining more source code
location information, would still be very useful, even if you don't manage
to land the whole NCG/Cmm part (GHCJS only uses STG).

luite

[1]
https://developer.chrome.com/devtools/docs/javascript-debugging#source-maps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141028/2e134185/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

GHC Weekly News - 10/24/2014

Jens Petersen-4
In reply to this post by Austin Seipp-5
Thanks for the Weekly News that is really useful info.

On 25 October 2014 09:00, Austin Seipp <austin at well-typed.com> wrote:

> Note: this post is available (with full hyperlinks) at
> https://ghc.haskell.org/trac/ghc/blog/weekly20141024
>


>  - This past week, a discussion sort of organically started on the
> `#ghc` IRC channel about the future of the LLVM backend. GHC's backend
> is buggy, has no control over LLVM versions, and breaks frequently
> with new versions. This all significantly impacts users, and relegates
> the backend to a second class citizen. After some discussion, Austin
> wrote up a proposal for a improved backend
> <https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend>, and wrangled
> several other
> people to help. The current plan is to try an execute this by GHC
> 7.12, with the goal of making the LLVM backend Tier 1 for major
> supported platforms.
>

Is this effort orthogonal to NCG for armv7 and armv8?

I am glad people are thinking about how to address this but
"we ship and fix a version of LLVM for GHC" sounds a bit scary to me. :)

Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141030/e281ee2f/attachment.html>

Reply | Threaded
Open this post in threaded view
|

GHC Weekly News - 10/24/2014

Austin Seipp-5
Yes, it is orthogonal to any effort for a NCG for ARMv7 or ARMv8.

Note that ARM is a platform that would particularly benefit from this:
right now, building GHC on ARM is a bit... er, troublesome. There are
a lot of LLVM versions that don't work, or are patched by maintainers
(making it impossible to know what might work or not), or have simply
never been tested depending on the distro. I've had quite my share of
problems trying to get GHC/ARM to build on ARM/Linux, due to all kinds
of incompatibilities or bugs in the code generator for whatever verson
I was using.

I agree that for upstreams (Debian, Fedora, etc) the proposition is a
bit scary perhaps. But I think the significant number of advantages
outweigh the disadvantages quite handily, and as we go forward, I
still think it will be the only truly maintainable solution, at least
in the forseeable future.

I am also of course more than willing to help upstreams adapt to this
(for example, should Debian or Fedora wish to package their own LLVM,
I'd be more than willing to help identify a version that works and we
could give to users).

FWIW, I'm aiming for not requiring any extra patches to LLVM. I'd
prefer using a stable version, and any bugs we find should go
upstream.( GHC requiring extra LLVM patches would be a possibility,
but one of the last things we'd want possibly due to extra
complication.)

On Thu, Oct 30, 2014 at 5:24 AM, Jens Petersen <juhpetersen at gmail.com> wrote:

> Thanks for the Weekly News that is really useful info.
>
> On 25 October 2014 09:00, Austin Seipp <austin at well-typed.com> wrote:
>>
>> Note: this post is available (with full hyperlinks) at
>> https://ghc.haskell.org/trac/ghc/blog/weekly20141024
>
>
>>
>>  - This past week, a discussion sort of organically started on the
>> `#ghc` IRC channel about the future of the LLVM backend. GHC's backend
>> is buggy, has no control over LLVM versions, and breaks frequently
>> with new versions. This all significantly impacts users, and relegates
>> the backend to a second class citizen. After some discussion, Austin
>> wrote up a proposal for a improved backend, and wrangled several other
>> people to help. The current plan is to try an execute this by GHC
>> 7.12, with the goal of making the LLVM backend Tier 1 for major
>> supported platforms.
>
>
> Is this effort orthogonal to NCG for armv7 and armv8?
>
> I am glad people are thinking about how to address this but
> "we ship and fix a version of LLVM for GHC" sounds a bit scary to me. :)
>
> Jens



--
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/