Re: testsuite failures in DEBUG

[Ben Gamari]

Joachim Breitner  writes:

> Hi,
>
> Am Freitag, den 26.01.2018, 23:23 -0500 schrieb Joachim Breitner:
>> Am Freitag, den 26.01.2018, 22:53 -0500 schrieb Richard Eisenberg:
>> > So: would it be possible to have our CI infrastructure validate
>> > DEBUG mode as well? Then it would be easy to spot where these
>> > failures are from.
>> 
>> unhelpful comment: Travis used to validate with DEBUG, but it no longer
>> runs the test suite for build time reason. So plausibly we could add a
>> -DEBUG variant to CircleCI?
>
> I now also stumble about the inability to properly test a build built
> with -DDEBUG.
>
> So let me rephrase: Could we please add a -DDEBUG variant to CircleCI?
>
See D4411.

> (And then fix the failing tests, or at least mark them as known-to-be-
> failing on a debugged GHC)

I'll add this to my list.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Looking for GSoC Mentor

[Andreas Klebinger]

Hello Everyone,
I'm looking for a mentor for a GSoC Project/Proposal.

The whole idea revolves around:
* Getting hot path information from static analysis and user annotations.
* Making sure it's not destroyed by optimization passes.
* Using it to generate better code where applicable.

See also:
#14672: Make likelihood of branches/conditions available throughout the 
compiler.



Towards these goals I would like for GSoC:
* Land https://phabricator.haskell.org/D4327(Branchweights in STG and Cmm)
  + It might be ready before then. But it's a prerequisite so worth 
listing here.

* Design and implement a way for users to:
  + Mark hot paths in Haskell code.
  + Push the information through the passes (up to STG) on a best 
effort basis. STG and beyond is part of the diff above.
  + The current backend already uses this information in some places, 
so this alone should lead to small but consistent gains.
  + I don't plan to add additional optimizations unless there is time 
left at the end.



Where I think I will need help/experience from a mentor is:
* Frontend questions:
  I haven't looked at GHC's parser/renamer yet so while
  this is surmountable I expect some questions to arise there.

* Design questions/feedback:
  Things like:
  + How should the user be able to give this information.
  + What should be flag controlled? What always on?
  + Things like compile time/executable speed tradeoffs.
  ...

* Potentially the simplifier:
  I've looked into it briefly as originally D4327 was aimed at the
  core stage instead of stg.
  There doesn't seem to be a lot that could
  mess with hot path information/branchweights. But I haven't worked on
  the simplifier before and it seems like a good place for unexpected
  issues to arise.

* If this involves the proposal process then also guidance there.

For myself:
* I'm studying at TU Vienna (Software & Information Engineering)
  and am close to finishing my undergrad. Located in Austria (UTC+1)
* I have contributed a few small changes to GHC throughout last year.
  See AndreasK on Phab/Trac.
* If you want to know more contact me!


If you are interested in mentoring me or looking for more details feel free
to contact me at klebinger.andr...@gmx.at 
or look for AndreasK in #ghc


Best Regards
Andreas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs