HDL generation failure with clash 1.8.1 ghc 9.4.7 about clash-compiler HOT 14 OPEN

PS. I have been able to locate the problem as stemming from a particular source code stanza. This does NOT generate error:

        -- strong inval, weak inval req
        f (Just x1,Just x2,Nothing,Just (idx1,v1),Just (idx2,v2)) = 
            let (idx1',tag1) = tacache_split_cxdr x1
                (idx2',tag2) = tacache_split_cxdr x2
            in
            if idx1' /= idx2' then
              let v1' = fst $ tazcache_line_inval_step v1 tag1
                  v2' = fst $ tazcache_line_weak_inval_step v2 tag2
              in ( if idx1 == idx1' then Just(idx1',v1') else Nothing
                 , if idx2 == idx2' then Just(idx2',v2') else Nothing
                 )
            else
              let v1' = fst $ tazcache_line_inval_step v1 tag1
                  v2' = fst $ tazcache_line_weak_inval_step v1' tag2
              in ( if idx2 == idx2' then Just(idx2',v2') else Nothing
                 , Nothing
                 )

This DOES generate error:

        -- strong inval, weak inval req
        f (Just x1,Just x2,Nothing,Just (idx1,v1),Just (idx2,v2)) = 
            let (idx1',tag1) = tacache_split_cxdr x1
                (idx2',tag2) = tacache_split_cxdr x2
            in
            if idx1' /= idx2' then
              let **(v1',_)** = tazcache_line_inval_step v1 tag1
                  **(v2' ,_)** = tazcache_line_weak_inval_step v2 tag2
              in ( if idx1 == idx1' then Just(idx1',v1') else Nothing
                 , if idx2 == idx2' then Just(idx2',v2') else Nothing
                 )
            else
              let **(v1',_)** = tazcache_line_inval_step v1 tag1
                  **(v2',_)** = tazcache_line_weak_inval_step __v1'__ tag2
              in ( if idx2 == idx2' then Just(idx2',v2') else Nothing
                 , Nothing
                 )

I've marked the difference in bold (hopefully - nope no hope, oh well, look for the double asterisks). It is pattern match for the first of a pair, vs applying fst. Also with v1 instead of v1' in that final else (marked with italics - ibid, look for the extra underlines fore and aft), everything is good with or without pattern match.

from clash-compiler.

That bug only appears when the function above is in a where clause to another function. Raise the function to top level (with the same type declarations) and there is no problem generating verilog.

win1,win2 :: Maybe (idx, Vec (2^m) (Maybe (tag, Maybe addr)))
(win1,win2) = f (dx, d_x, dw, out1, out2)
where f :: ( Maybe cxdr , Maybe cxdr, Maybe(cxdr,addr), Maybe (idx,Vec(2^m)(Maybe(tag,Maybe addr))), Maybe (idx,Vec(2^m) (Maybe(tag,Maybe addr))))
-> ( Maybe(idx,CacheLine m tag addr), Maybe(idx,CacheLine m tag addr))
....

Yes, that is also a where clause in another function. The specialization of those type variables was originally left to much higher in the call hierarchy but in the effort to pin down the problem I specialized them lower and lower down and the governing constraints are now:

forall (m::Nat) (n::Nat) (p::Nat) (q::Nat) cxdr addr idx tag
. ( KnownNat q, KnownNat n, KnownNat m, KnownNat p
, n <= p, cxdr ~ Signed p, addr ~ Signed q, idx ~ Signed n, tag ~ Signed (p-n)
)

but that has never made any difference one way or another.

So, in summary, at top level the function "f" causes no verilog generation problems. In a (second level) where clause it stops verilog generation with error indicating not enough lowe level terms in a tuple, so they have been disapeared. That is repaired even when in the where clause by making the trivial change of replacing a (foo,_) = pattern with a foo = fst $ .

from clash-compiler.

I would be very helpful if you could provide a Short, Self Contained, Correct (Compilable), Example that demonstrates the problem.

from clash-compiler.

from clash-compiler.

To add some context, this error usually disappears when I try to pin it, which is not easy because it has always manifested first as "never produces output" in large compilations. So finding out which part of the code it is in requires binary search and use of a stopwatch.

It is quite common ... it seems to be at about the 1:30000 lines of code level. That is, three instances per 100000 lines of code. The commonalities in the instances I have seen (roughly) are that they all manipulate streams, not data. The example above I obtained by replacing the manipulation of streams by a mealy machine with a nil state. The state transform part then got sliced up until I got down to the stanza above which evokes the hdl generation error shown. Putting that part as a top level function instead of a local function inside a "where" for the mealy machine state transform fixes the error and hdl generation works again.

I have just seen an instance in which foo ... bar ... generates verilog perfectly, but when bar is replaced with gum which also generates verilog perfectly, then it doesn't work. Foo and bar and gum are noinline and defined in different modules. By "doesn't work" I mean silently never produces output, the clash verilog generation just runs forever.

All these codes work fine for hdl generation under clash 1.6.4 on the same machine. I am wondering if perhaps the way this clash was compiled may be the problem (I am using the one from debian, except that I recompiled it to put in more error reporting, but I would have used the same infrastructure as the debian build). About all the info I can get out is "Glasgow Haskell Compiler, Version 9.4.7, stage 2 booted by GHC version 9.4.7". Maybe optimization flags were overoptimistic or something similar.

I'll make an effort today to further isolate a piece of code that you can use as a testbed, but I would urge a look at the mkDcApplication function to see what it does with those arguments from the error printout. Hopefully supplying them to it is "just" a matter of editing the error output.

Regards

PTB

from clash-compiler.

I've gathered code that evokes the error into the attached self-contained file. It's a delicate bug so I haven't dared trim beyond what is there. I have commented with FIX changes to make verilog generation work. It is to replace (v,_) = with v = fst $ at the indicated places, and to replace the indicated case stanzas each with a call to a new top level function that contains just that stanza. Please run verilog generation on the code and confirm the error.

I don't think any of the cache_line support functions are involved, I have replaced them with dummies of the same type in the past without affecting things one way or the other. Please cut and slice away. I'll try reducing this further too. It's just so tricky to pin that I want to record this and see if you agree that it evokes an error on your platform. Instructions on command line to run are at top of file, with the recorded output.

Regards

PTB
Test.hs.txt

from clash-compiler.