Help on first ticket

Sun Aug 14 10:01:21 UTC 2016

Hello Richard,

It is certainly hard work on the first ticket. I spent about an hour
this morning trying to find out where the right part to change was and
then read Ben's email earlier in this thread which made everything
much clearer for me!

The essential problem we are trying to solve is:

> When a module is compiled with -O0, it does not read unfoldings from modules it imports. Because we reuse the unfolding information across modules (to avoid reloading interface files very often), this unfolding information is then not available in the rest of the compilation pipeline.

Simon's suggested fix is

1. Always read in unfoldings, etc, including with -O. (Possible
exception: one-shot mode.)
2. Check the -fignore-interface-pragmas flag when considering inlining
a function.

So for part 1, we need to find the part which deals with *reading in*
interface files and seeing where the unfolding information is lost.

For part 2, we need to find the part of the optimiser which makes
decisions about whether to inline a function.

So now I'm re-reading Ben's comment and (as usual) his analysis is
spot-on. If you trace the origin of the ignore_prags flag then you'll
find it is set by checking whether the option
`Opt_IgnoreInterfacePragmas` is set or not. You can find that this
flag is automatically set when the opt-level is 0 in DynFlags, I'll
leave you to find the exact location!

It seems like Simon's suggested fix is removing this guard in
loadDecls. It isn't clear to me whether the other information (other
than the unfoldings) should still be read in or not. Simon will be
able to comment.

Now for part 2: I think you should start by looking at the
callSiteInline function in coreSyn/CoreUnfold. That will at least get
you started looking in the right place.

Does that help?

Matt

On Sun, Aug 14, 2016 at 2:40 AM, Richard Fung <minesasecret at gmail.com> wrote:
> Hello! Sorry for taking so long on this..
>
> I am still struggling with it and feel like I should probably ask for some
> assistance or guidance at this point.
>
> I think I am beginning to understand the first half of this: making sure
> that the inlining information is saved regardless of the optimization level.
> It seems like I need to change the functions that are called from
> tidyProgram which take the variable omit_prags?
>
> However, I am completely lost as to where this inlining takes place.. I have
> been trying to look at simplifyPgm in SimplCore.hs, but haven't really been
> able to see where the inlining happens..
>
> Could anyone give me any suggestions? I'm beginning to wonder if I'm in over
> my head as this is my first time working on a compiler so almost everything
> is new to me. On the other hand I'm certainly learning a lot along the way.
>
> On Tue, Aug 9, 2016 at 8:34 AM, Richard Fung <minesasecret at gmail.com> wrote:
>>
>>
>> ---------- Forwarded message ----------
>> From: Richard Fung <minesasecret at gmail.com>
>> Date: Tue, Aug 9, 2016 at 8:33 AM
>> Subject: Re: Help on first ticket
>> To: Simon Peyton Jones <simonpj at microsoft.com>
>>
>>
>> It's been a while but I've been able to spend more time on it recently
>> made some progress.
>>
>> I believe I have an idea of what I need to fix in terms of the generating
>> of ModDetails/ModInfo. First off, please tell me if this is wrong.. it seems
>> like ModDetails is made in mkBootModDetailsTc and tidyProgram. In
>> tidyProgram there are several functions which take omit_prags, which I think
>> is automatically set to True on -O0. These are the things we'll have to
>> change because they are used in mkIface_ to generate the [IfaceDecl] used to
>> make ModInfo in addFingerprints.
>>
>> Hopefully I'm understanding that part correctly. However, I'm not really
>> sure how to write a proper test case for this ticket. Also, I think I have
>> an idea of where to start looking for the place the inlining/unfolding
>> happens but pointers definitely wouldn't hurt.
>>
>> Thanks and sorry this is taking me so long!
>>
>> On Fri, Jun 24, 2016 at 12:26 PM, Simon Peyton Jones
>> <simonpj at microsoft.com> wrote:
>>>
>>> Great.  No rush.  Yell if you need help.
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> From: Richard Fung [mailto:minesasecret at gmail.com]
>>> Sent: 24 June 2016 19:05
>>> To: Simon Peyton Jones <simonpj at microsoft.com>
>>> Cc: ghc-devs at haskell.org
>>>
>>>
>>> Subject: Re: Help on first ticket
>>>
>>>
>>>
>>> Hi Simon, I am making progress but slowly (I only have time to work on
>>> this outside of work unfortunately).
>>>
>>>
>>>
>>> If this needs to be done soon feel free to reassign it to someone else!
>>> Otherwise, while at times I feel like I'm over my head I would like to keep
>>> at it.
>>>
>>>
>>>
>>> On Fri, Jun 24, 2016 at 4:20 AM, Simon Peyton Jones
>>> <simonpj at microsoft.com> wrote:
>>>
>>> Richard, did you get on ok?
>>>
>>> Simon
>>>
>>>
>>> |  -----Original Message-----
>>> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ben
>>> |  Gamari
>>> |  Sent: 04 June 2016 23:20
>>> |  To: Richard Fung <minesasecret at gmail.com>; ghc-devs at haskell.org
>>> |  Subject: Re: Help on first ticket
>>> |
>>> |  Richard Fung <minesasecret at gmail.com> writes:
>>> |
>>> |  > Hello! I apologize if this isn't the right place to ask; if it isn't
>>> |  > please steer me in the right direction.
>>> |  >
>>> |  Hi Richard!
>>> |
>>> |  > Would anyone be willing to advise me on my first ticket? I've been
>>> |  > trying to work on it on and off but haven't made much progress on my
>>> |  own.
>>> |  >
>>> |  > It's ticket #9370: https://ghc.haskell.org/trac/ghc/ticket/9370
>>> |  >
>>> |  Great, I'm happy to hear that someone has picked this one up. I think
>>> |  it is a nice choice for a self-contained newcomers project.
>>> |
>>> |  > I think I understand the issue conceptually but I don't know where
>>> |  to
>>> |  > look for the code that needs to be changed..
>>> |  >
>>> |  I don't know where the code responsible for this is off the top of my
>>> |  head, however I can provide some pointers.
>>> |
>>> |  So the unfoldings you are looking to preserve come from interface
>>> |  files.
>>> |  The machinery for all of this is in compiler/iface. IfaceSyn.hs is of
>>> |  particular interest and there you will find the definition of
>>> |  IfaceUnfolding, which is the unfolding representation which is stored
>>> |  in the interface file. Unfoldings live inside of IdInfo values, which
>>> |  hold various miscellaneous information which we need to preserve about
>>> |  a particular Id (identifier).
>>> |
>>> |  There is a somewhat useful comment regarding how IdInfo is treated
>>> |  above the definition of IfaceIdInfo in IfaceSyn. In particular it
>>> |  seems that interface files for modules compiled with -O0 will have
>>> |  their IdInfo fields set to NoInfo. It's not clear what happens when an
>>> |  interface file is read. However, grepping for NoInfo reveals a use-
>>> |  site in TcIface.tcIdInfo which looks interesting (in particular the
>>> |  ignore_prags guard). I think this should be enough to get you going on
>>> |  the interface file part of this.
>>> |
>>> |  The other part of this ticket is deciding whether to use an unfolding
>>> |  when considering whether to inline. This will be done in the
>>> |  simplifier (compiler/simplCore). Grepping for "inline" and "unfold" in
>>> |  simplCore/Simplify.hs (as well as reading the notes in that file) will
>>> |  likely be enough to get you started.
>>> |
>>> |  Do let me know if you still feel lost or want to discuss this further.
>>> |  I look forward to hearing how it goes.
>>> |
>>> |  Cheers,
>>> |
>>> |  - Ben
>>>
>>> |  _______________________________________________
>>> |  ghc-devs mailing list
>>> |  ghc-devs at haskell.org
>>> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
>>> |  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
>>> |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5ce47a744a1448f
>>> |  ff5cb08d38cc666b8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=V22RG%2
>>> |  fAiO1lD5bLCR%2fXz2jv5QCzYAK5HUi6dDaAFQLA%3d
>>>
>>>
>>
>>
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>