-
Notifications
You must be signed in to change notification settings - Fork 155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Couldn't instantiate blackbox for Clash.Sized.Vector.replicate.
unless manually marked for inlining
#1454
Couldn't instantiate blackbox for Clash.Sized.Vector.replicate.
unless manually marked for inlining
#1454
Comments
Something has gone horribly wrong at the GHC side. I'm seeing this in Test.$sinitBCD_g
= replicate
@ (CLog 10 (2 ^ 8))
@ (Unsigned 4)
(Clash.Promoted.Nat.SNat
@ (CLog 10 (2 ^ 8))
(case BCD.initBCD2 of {
GHC.Natural.NatS# a1_ap0t ->
Test.$s$w$cnatSing2
`cast` (GHC.TypeLits.KnownNat.N:SNatKn[0]
<"GHC.TypeLits.Extra.CLog">_P ; (Sym (GHC.TypeNats.N:SNat[0]
<CLog
10
(2
^ 8)>_P) ; Sym (GHC.TypeNats.N:KnownNat[0]) <CLog
10
(2
^ 8)>_N)
:: GHC.TypeLits.KnownNat.SNatKn "GHC.TypeLits.Extra.CLog"
~R# KnownNat (CLog 10 (2 ^ 8)));
GHC.Natural.NatJ# dt_apaH ->
case {__pkg_ccall integer-gmp-1.0.2.0 ByteArray#
-> ByteArray#
-> Int#
-> State# RealWorld
-> (# State# RealWorld, Int# #)}_apaT
dt_apaH
dt_apaH
(GHC.Prim.uncheckedIShiftRL#
(GHC.Prim.sizeofByteArray# dt_apaH) 3#)
GHC.Prim.realWorld#
of
{ (# ds2_apaW, ds3_apaX #) ->
Test.$s$w$cnatSing2
`cast` (GHC.TypeLits.KnownNat.N:SNatKn[0]
<"GHC.TypeLits.Extra.CLog">_P ; (Sym (GHC.TypeNats.N:SNat[0]
<CLog
10
(2
^ 8)>_P) ; Sym (GHC.TypeNats.N:KnownNat[0]) <CLog
10
(2
^ 8)>_N)
:: GHC.TypeLits.KnownNat.SNatKn "GHC.TypeLits.Extra.CLog"
~R# KnownNat (CLog 10 (2 ^ 8)))
}
}))
(Clash.Sized.Internal.Unsigned.fromInteger#
@ 4
(BCD.add1
`cast` (Sym (GHC.TypeNats.N:SNat[0]
<4>_P) ; Sym (GHC.TypeNats.N:KnownNat[0]) <4>_N
:: GHC.Natural.Natural ~R# KnownNat 4))
0) The important bit there is However, when I look it up I see: Test.$s$w$cnatSing2
= case GHC.Integer.Logarithms.integerLogBase#
Test.$s$w$cnatSing2_x1 Test.$s$w$cnatSing2_y1
of z1_aqy6
{ __DEFAULT ->
case GHC.Integer.Logarithms.integerLogBase#
Test.$s$w$cnatSing2_x1
(integer-gmp-1.0.2.0:GHC.Integer.Type.minusInteger
Test.$s$w$cnatSing2_y1
GHC.TypeLits.Extra.$fKnownNat2"GHC.TypeLits.Extra.CLog"xy2)
of z2_aqy8
{ __DEFAULT ->
case integer-gmp-1.0.2.0:GHC.Integer.Type.eqInteger#
Test.$s$w$cnatSing2_y1
GHC.TypeLits.Extra.$fKnownNat2"GHC.TypeLits.Extra.CLog"xy2
of {
__DEFAULT ->
case GHC.Prim.==# z1_aqy6 z2_aqy8 of {
__DEFAULT ->
(GHC.Natural.NatS# (GHC.Prim.int2Word# z1_aqy6))
`cast` (Sym (GHC.TypeLits.KnownNat.N:SNatKn[0]
<"GHC.TypeLits.Extra.CLog">_P)
:: GHC.Natural.Natural
~R# GHC.TypeLits.KnownNat.SNatKn "GHC.TypeLits.Extra.CLog");
1# ->
(GHC.Natural.NatS# (GHC.Prim.int2Word# (GHC.Prim.+# z1_aqy6 1#)))
`cast` (Sym (GHC.TypeLits.KnownNat.N:SNatKn[0]
<"GHC.TypeLits.Extra.CLog">_P)
:: GHC.Natural.Natural
~R# GHC.TypeLits.KnownNat.SNatKn "GHC.TypeLits.Extra.CLog")
};
1# ->
GHC.TypeLits.Extra.$fKnownNat2"GHC.TypeLits.Extra.CLog"xy1
`cast` (Sym (GHC.TypeLits.KnownNat.N:SNatKn[0]
<"GHC.TypeLits.Extra.CLog">_P)
:: GHC.Natural.Natural
~R# GHC.TypeLits.KnownNat.SNatKn "GHC.TypeLits.Extra.CLog")
}
}
} again, the important part of that is: case GHC.Integer.Logarithms.integerLogBase#
Test.$s$w$cnatSing2_x1 Test.$s$w$cnatSing2_y1
of z1_aqy6 where
but
So |
When I add |
My guess is that It might because we only tag the evidence with the (string representation of the) name of the operation ("CLog" in the above case): I'll see what happens if I tag the evidence with all the parameters. |
For some bizarre reason, which I cannot reproduce, the set of optimizations that Clash picks results in a weird specialization of the `natSing2` implementation for `GHC.TypeNats.^`, which is specialized to the `y` in `x ^ y` being a negative number. This then causes the: > shiftL x y = if y <= 0 then shiftLNatural x y else shiftRNatural x (negate y) to pick the else branch, which in turn causes fast power-of-two calculation in `natSing2` to do `1 shiftR y` instead of the intended `1 shiftL y`. Anyhow... I don't know what's going on... This patch ensures we call `shiftLNatural` directly, since we know the exponent never a negative number; and GHC won't be able to specialize. Fixes clash-lang/clash-compiler#1454
For some bizarre reason, which I cannot reproduce, the set of optimizations that Clash picks results in a weird specialization of the `natSing2` implementation for `GHC.TypeNats.^`, which is specialized to the `y` in `x ^ y` being a negative number. This then causes the: > shiftL x y = if y <= 0 then shiftLNatural x y else shiftRNatural x (negate y) to pick the else branch, which in turn causes fast power-of-two calculation in `natSing2` to do `1 shiftR y` instead of the intended `1 shiftL y`. Anyhow... I don't know what's going on... This patch ensures we call `shiftLNatural` directly, since we know the exponent never a negative number; and GHC won't be able to specialize. Fixes clash-lang/clash-compiler#1454
@gergoerdi This will be fixed by clash-lang/ghc-typelits-knownnat#36 |
For some bizarre reason, which I cannot reproduce, the set of optimizations that Clash picks results in a weird specialization of the `natSing2` implementation for `GHC.TypeNats.^`, which is specialized to the `y` in `x ^ y` being a negative number. This then causes the: > shiftL x y = if y <= 0 then shiftLNatural x y else shiftRNatural x (negate y) to pick the else branch, which in turn causes fast power-of-two calculation in `natSing2` to do `1 shiftR y` instead of the intended `1 shiftL y`. Anyhow... I don't know what's going on... This patch ensures we call `shiftLNatural` directly, since we know the exponent never a negative number; and GHC won't be able to specialize. Fixes clash-lang/clash-compiler#1454
This was quite challenging to minimize into a standalone program, but here it is. It requires splitting into two modules to demonstrate the problem.
BCD.hs
Top.hs
As is, this when compiling to Verilog, with the following error message:
What I have found is that I can work around this problem by manually adding an
INLINE
pragma toinitBCD
andtoBCD
. This set seems to be minimal, as in addingINLINE
to just any one of them doesn't fix the problem.The text was updated successfully, but these errors were encountered: