Replace usage of `typeof` (inferred) by `Core.Typeof` (runtime)

[torfjelde]

This is per @wsmoses suggestion after a chat we (and @mhauru ) had earlier today.

It's an attempt to fix some issues we've had with Enzyme.jl-integration; in particular, https://github.com/TuringLang/DynamicPPL.jl/issues/643

[coveralls]

Pull Request Test Coverage Report for Build 9749798418

Details

• 2 of 2 (100.0%) changed or added relevant lines in 2 files are covered.
• 24 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-0.9%) to 76.624%

---

Files with Coverage Reduction	New Missed Lines	%
src/model.jl	1	88.35%
src/abstract_varinfo.jl	9	82.68%
src/threadsafe.jl	14	48.25%
<!--	Total:	24		-->

Totals
Change from base Build 9678167735:	-0.9%
Covered Lines:	2642
Relevant Lines:	3448

---

💛 - Coveralls

[coveralls]

Pull Request Test Coverage Report for Build 9749858036

Details

• 3 of 3 (100.0%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 77.531%

---

Totals
Change from base Build 9678167735:	0.0%
Covered Lines:	2657
Relevant Lines:	3427

---

💛 - Coveralls

[torfjelde]

Unfortately doesn't seem to address the issue in https://github.com/TuringLang/DynamicPPL.jl/issues/643 nor the failing one herehttps://github.com/torfjelde/EnzymeCon2024-Turing.jl-benchmarks/blob/main/src/models/fails/satellite-ssm-matrix.jl 😕

[torfjelde]

I think I'll have to defer to @wsmoses for your comments @devmotion . From convo with him, I sort of got the impression that we wanted to avoid typeof and we were hypothesizing if that might have been a cause of an Enzyme issue; seems like it's not though 😕

[torfjelde]

Converted to DRAFT though because it wasn't my intention to have this be merged into master atm; just for Enzyme testing

[wsmoses]

Having not looked at the code changes here yet. @devmotion the context here is a program tor had which failed when compiled with GPUComojler with an error along the lines of cannot construct matrix{any}. This was not from any differentiation, but just GPUComojler calling the Julia compiler itself (though perhaps with different flags for say inlining).

Our hypothesis was that somewhere this matrix (which wasn't supported by a later function resulting in the guaranteed error), was being constructed by the use of the inferred type of rather than runtime type.

The fact that it fails in this way implies the use of some undefined behavior (eg the Julia compiler choosing to inline a function differently causing its body to have an underspecializdd type vs more specialized).

I recommended Tor see if propagating the use of the actual runtime type would resolve it here, but if not Tor you're going to have to see what other use of undefined behavior results in the matrix any in your example

On Tue, Jul 2, 2024, 10:16 AM Tor Erlend Fjelde @.***> wrote:

Converted to DRAFT though because it wasn't my intention to have this be merged into master atm; just for Enzyme testing

— Reply to this email directly, view it on GitHub https://github.com/TuringLang/DynamicPPL.jl/pull/627#issuecomment-2202471673, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJTUXFLXWBADHMK6IUWJ5TZKJVXLAVCNFSM6AAAAABKGEMTZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBSGQ3TCNRXGM . You are receiving this because you were mentioned.Message ID: @.***>

[torfjelde]

I recommended Tor see if propagating the use of the actual runtime type would resolve it here, but if not Tor you're going to have to see what other use of undefined behavior results in the matrix any in your example

Noted! But I'm unfortunately short on time these days, so uncertain if I'll be the best one to have a go at this. Might be better for @mhauru to have a look at it? In particular given that you two are co-hacking atm:)

[mhauru]

I can take a look, may take may a few days to get to this.

[yebai]

Ref: https://github.com/TuringLang/DynamicPPL.jl/issues/643