FilterBank benchmark in C++ has cycles

[edwardalee]

In the reaction-self-loop branch, we fix a bug where causality loops were not detected when a reaction triggers itself. This exposed a bug in the FilterBanks C++ benchmarks. It has causality loops. These may actually interfere with the validity of the benchmark results...

[cmnrd]

There is no dependency cycle in FilterBank (otherwise it should have been reported by the C++ runtime). This is actually a bug in the dependency analysis or in the instance graph.

In the Bank reactor, these connection statements are used to create the pipeline:

inFinished, delay0.outFinished, fir0.outFinished, sample.outFinished, delay1.outFinished, fir1.outFinished -> 
    delay0.inFinished, fir0.inFinished, sample.inFinished, delay1.inFinished, fir1.inFinished, outFinished;
        
inValue, delay0.outValue, fir0.outValue, sample.outValue, delay1.outValue, fir1.outValue -> 
    delay0.inValue, fir0.inValue, sample.inValue, delay1.inValue, fir1.inValue, outValue;

Admittedly these connection statements are a bit complex and might be unintuitive, but I wanted to explore the possibilities of our connection syntax to compactly create a pipeline. Note that there are no backedges here. Both connection statements form a pipeline where the output of one stage is forwarded to the next (delay0 -> fir0 -> sample -> delay1 -> fir1). This uses the same principle as in the Pipeline example, only here we don't use N times the same stage but combine different stages.

But indeed the corresponding diagram shows cycles:

When I manually unroll the connection statements like so

    inFinished -> delay0.inFinished
    delay0.outFinished -> fir0.inFinished
    fir0.outFinished -> sample.inFinished
    sample.outFinished -> delay1.inFinished
    delay1.outFinished -> fir1.inFinished
    fir1.outFinished -> outFinished
         
    inValue -> delay0.inValue
    delay0.outValue -> fir0.inValue
    fir0.outValue -> sample.inValue
    sample.outValue -> delay1.inValue
    delay1.outValue -> fir1.inValue
    fir1.outValue -> outValue   

then the diagram shows the pipeline without back-edges and there is no cycle detected.

[lhstrh]

Some investigation revealed a bug in the compiler (as well as an opportunity for optimization of the generated code). A minimal test that illustrates the problem can be found here in the ganged-connections branch. The plan is to 1) develop a fix in this branch, and 2) for the time being, replace the problematic connect statement in the benchmark so that we can safely merge the fix in #1026 without having any failures in the benchmark tests.

[edwardalee]

This should be fixed by #1037. But one observation is that using this style of ganged connections may be much less efficient, at least in the C target.