Bug in SRT generation for procs in .cmm files?

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

Bug in SRT generation for procs in .cmm files?

Ömer Sinan Ağacan
Hi Simon,

Currently CmmParse only generates CmmLabels for procs, and those are considered
non-CAFFY by hasCAF (and thus CmmBuildInfoTables).

As a result if I have two procs in a .cmm file:

- p1, refers to a CAF in base
- p2, refers to p1

I *think* (haven't checked) we don't consider p1 as CAFFY, and even if we do, we
don't consider p2 as CAFFY becuase the reference from p2 to p1 won't be
considered CAFFY by hasCAF.

So we currently can't define a CAFFY Cmm proc in .cmm files as the SRT algorithm
will never build SRTs for procs in .cmm files.

Is this intentional? I'd expect this to be possible, because there's nothing
preventing me from referring to a CAFFY definition in a library (e.g. base) in a
.cmm file, but doing this would be a bug in runtime.

Thanks,

Ömer
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Bug in SRT generation for procs in .cmm files?

Ben Gamari-3
While it's true that in principle one could imagine a case where you would want a CAFfy Cmm proc, I can't think of any stuck cases in the RTS today. Consequently it wouldn't surprise me if this was broken.

Frankly, I wouldn't worry too much about this if it's nontrivial to fix.

Cheers,

- Ben

On January 23, 2020 1:54:04 AM EST, "Ömer Sinan Ağacan" <[hidden email]> wrote:
Hi Simon,

Currently CmmParse only generates CmmLabels for procs, and those are considered
non-CAFFY by hasCAF (and thus CmmBuildInfoTables).

As a result if I have two procs in a .cmm file:

- p1, refers to a CAF in base
- p2, refers to p1

I *think* (haven't checked) we don't consider p1 as CAFFY, and even if we do, we
don't consider p2 as CAFFY becuase the reference from p2 to p1 won't be
considered CAFFY by hasCAF.

So we currently can't define a CAFFY Cmm proc in .cmm files as the SRT algorithm
will never build SRTs for procs in .cmm files.

Is this intentional? I'd expect this to be possible, because there's nothing
preventing me from referring to a CAFFY definition in a library (e.g. base) in a
.cmm file, but doing this would be a bug in runtime.

Thanks,

Ömer
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Bug in SRT generation for procs in .cmm files?

Ömer Sinan Ağacan
The main problem I'm trying to solve is explained in my comment [1]. Basically
when building .cmm files the new SRT algorithm re-order definitions in a way
that breaks dependency ordering, which in turn breaks C backend, because in C we
should declare before using. (see my comment for why we don't have this problem
when building Haskell modules)

If we don't allow defining CAFFY things in Cmm files then I can simply not do
SRT analysis on Cmm files and avoid the problem.

Ömer

[1]: https://gitlab.haskell.org/ghc/ghc/merge_requests/1304#note_248547

Ben Gamari <[hidden email]>, 23 Oca 2020 Per, 15:17 tarihinde şunu yazdı:

>
> While it's true that in principle one could imagine a case where you would want a CAFfy Cmm proc, I can't think of any stuck cases in the RTS today. Consequently it wouldn't surprise me if this was broken.
>
> Frankly, I wouldn't worry too much about this if it's nontrivial to fix.
>
> Cheers,
>
> - Ben
>
> On January 23, 2020 1:54:04 AM EST, "Ömer Sinan Ağacan" <[hidden email]> wrote:
>>
>> Hi Simon,
>>
>> Currently CmmParse only generates CmmLabels for procs, and those are considered
>> non-CAFFY by hasCAF (and thus CmmBuildInfoTables).
>>
>> As a result if I have two procs in a .cmm file:
>>
>> - p1, refers to a CAF in base
>> - p2, refers to p1
>>
>> I *think* (haven't checked) we don't consider p1 as CAFFY, and even if we do, we
>> don't consider p2 as CAFFY becuase the reference from p2 to p1 won't be
>> considered CAFFY by hasCAF.
>>
>> So we currently can't define a CAFFY Cmm proc in .cmm files as the SRT algorithm
>> will never build SRTs for procs in .cmm files.
>>
>> Is this intentional? I'd expect this to be possible, because there's nothing
>> preventing me from referring to a CAFFY definition in a library (e.g. base) in a
>> .cmm file, but doing this would be a bug in runtime.
>>
>> Thanks,
>>
>> Ömer
>> ________________________________
>> ghc-devs mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Bug in SRT generation for procs in .cmm files?

Simon Marlow-7
Yes, I think my assumption was that we wouldn't be referring to any CAFs from .cmm source code so we didn't need to track the CAFyness of labels. It would be quite a pain to support this I think - in .cmm you can refer to anything by its raw label, so we would have to either declare whether something is CAFy or reverse engineer the original entity name and load the interface file etc.  Furthermore we would need to tell the compiler about the CAFyness of RTS labels somehow so that they could be added to SRTs where necessary.

I'm fine with not running the SRT analysis on .cmm code.

Cheers
Simon


On Thu, 23 Jan 2020 at 14:57, Ömer Sinan Ağacan <[hidden email]> wrote:
The main problem I'm trying to solve is explained in my comment [1]. Basically
when building .cmm files the new SRT algorithm re-order definitions in a way
that breaks dependency ordering, which in turn breaks C backend, because in C we
should declare before using. (see my comment for why we don't have this problem
when building Haskell modules)

If we don't allow defining CAFFY things in Cmm files then I can simply not do
SRT analysis on Cmm files and avoid the problem.

Ömer

[1]: https://gitlab.haskell.org/ghc/ghc/merge_requests/1304#note_248547

Ben Gamari <[hidden email]>, 23 Oca 2020 Per, 15:17 tarihinde şunu yazdı:
>
> While it's true that in principle one could imagine a case where you would want a CAFfy Cmm proc, I can't think of any stuck cases in the RTS today. Consequently it wouldn't surprise me if this was broken.
>
> Frankly, I wouldn't worry too much about this if it's nontrivial to fix.
>
> Cheers,
>
> - Ben
>
> On January 23, 2020 1:54:04 AM EST, "Ömer Sinan Ağacan" <[hidden email]> wrote:
>>
>> Hi Simon,
>>
>> Currently CmmParse only generates CmmLabels for procs, and those are considered
>> non-CAFFY by hasCAF (and thus CmmBuildInfoTables).
>>
>> As a result if I have two procs in a .cmm file:
>>
>> - p1, refers to a CAF in base
>> - p2, refers to p1
>>
>> I *think* (haven't checked) we don't consider p1 as CAFFY, and even if we do, we
>> don't consider p2 as CAFFY becuase the reference from p2 to p1 won't be
>> considered CAFFY by hasCAF.
>>
>> So we currently can't define a CAFFY Cmm proc in .cmm files as the SRT algorithm
>> will never build SRTs for procs in .cmm files.
>>
>> Is this intentional? I'd expect this to be possible, because there's nothing
>> preventing me from referring to a CAFFY definition in a library (e.g. base) in a
>> .cmm file, but doing this would be a bug in runtime.
>>
>> Thanks,
>>
>> Ömer
>> ________________________________
>> ghc-devs mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs