Infinite loop (?) in Infer Widths pass.

As far as I can tell, I’m experiencing an infinite loop in the Infer Widths pass. It runs for ~3 minutes and then crashes the GC due to an OOM error.

There is no way obvious way for me to diagnosis this or figure out where in my Chisel design this error originates from.

[INFO] Starting Infer Widths
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
    at firrtl.Utils$.firrtl$Utils$$apply_t$1(Utils.scala:672)
    at firrtl.Utils$$anonfun$firrtl$Utils$$apply_t$1$1.apply(Utils.scala:672)
    at firrtl.Utils$$anonfun$firrtl$Utils$$apply_t$1$1.apply(Utils.scala:672)
    at firrtl.Mappers$TypeMagnet$$anon$8$$anonfun$map$1.apply(Mappers.scala:155)
    at firrtl.Mappers$TypeMagnet$$anon$8$$anonfun$map$1.apply(Mappers.scala:155)
    at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:245)
    at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:245)
    at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59)
    at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:48)
    at scala.collection.TraversableLike$class.map(TraversableLike.scala:245)
    at scala.collection.AbstractTraversable.map(Traversable.scala:104)
    at firrtl.Mappers$TypeMagnet$$anon$8.map(Mappers.scala:155)
    at firrtl.Mappers$TypeMap.map(Mappers.scala:172)
    at firrtl.Utils$.firrtl$Utils$$apply_t$1(Utils.scala:672)
    at firrtl.Utils$$anonfun$firrtl$Utils$$apply_t$1$1.apply(Utils.scala:672)
    at firrtl.Utils$$anonfun$firrtl$Utils$$apply_t$1$1.apply(Utils.scala:672)
    at firrtl.Mappers$TypeMagnet$$anon$8$$anonfun$map$1.apply(Mappers.scala:155)
    at firrtl.Mappers$TypeMagnet$$anon$8$$anonfun$map$1.apply(Mappers.scala:155)
    at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:245)
    at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:245)
    at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59)
    at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:48)
    at scala.collection.TraversableLike$class.map(TraversableLike.scala:245)
    at scala.collection.AbstractTraversable.map(Traversable.scala:104)
    at firrtl.Mappers$TypeMagnet$$anon$8.map(Mappers.scala:155)
    at firrtl.Mappers$TypeMap.map(Mappers.scala:172)
    at firrtl.Utils$.firrtl$Utils$$apply_t$1(Utils.scala:672)
    at firrtl.Utils$$anonfun$firrtl$Utils$$apply_t$1$1.apply(Utils.scala:672)
    at firrtl.Utils$$anonfun$firrtl$Utils$$apply_t$1$1.apply(Utils.scala:672)
    at firrtl.Mappers$TypeMagnet$$anon$8$$anonfun$map$1.apply(Mappers.scala:155)
    at firrtl.Mappers$TypeMagnet$$anon$8$$anonfun$map$1.apply(Mappers.scala:155)
    at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:245)
make: *** [/scratch/celio/boom-chip/emulator/generated-src/Top.BOOML1Config.v] Error 1

[azidar]

From what I can tell, the problem stems from the number of Firrtl objects in BOOM after the Expand Whens pass (when the circuit is in Middle Firrtl Form). At this point in time in the compiler, all connections/whens/etc. have been expanded. However, the Firrtl types have not been lowered. This means that simple connections have now expanded into a much larger number of statements, and those statements contain even more expressions to index the aggregate type. Finally, those expressions each have a type, often represented by a huge bundle type. Below is a simple circuit illustrating the issue.

To estimate the memory footprint, we will count the number of strings in the in-memory Firrtl representation of each statement. To start, we have two Bundle-typed wires, and we connect them (High Firrtl).

wire a: {x: {i: UInt, j: UInt}, y: {i: UInt, j: UInt}} //7
wire b: {x: {i: UInt, j: UInt}, y: {i: UInt, j: UInt}} //7
a <= b //7 + 7 (remember each reference has a type which contains strings)

totaling 28 strings. In the point of the compiler after the ExpandWhens pass (Middle Firrtl), we see:

wire a: {x: {i: UInt, j: UInt}, y: {i: UInt, j: UInt}} //7
wire b: {x: {i: UInt, j: UInt}, y: {i: UInt, j: UInt}} //7
a.x.i <= b.x.i //7+3+1 + 7 + 3 + 1 = 22
a.x.j <= b.x.j //22
a.y.i <= b.y.i //22
a.y.j <= b.y.j //22

totaling 102 Strings. After Lower Types (Low Firrtl):

wire a_x_i: UInt //1
wire a_x_j: UInt //1
wire a_y_i: UInt //1
wire a_y_j: UInt //1
wire b_x_i: UInt //1
wire b_x_j: UInt //1
wire b_y_i: UInt //1
wire b_y_j: UInt //1
a_x_i <= b_x_i //2
a_x_j <= b_x_j //2
a_y_i <= b_y_i //2
a_y_j <= b_y_j //2

Totaling 16 strings.

When compiling Boom, width inference is run on High Firrtl, Middle Firrtl, and Low Firrtl. It succeeds on High and Low, but fails in Middle. Fortunately, width inference is not necessary to run more than once, but we do it anyways just sort of because. I’ve made a change to add-chirrtl-check which removes the second running of width inference, and now Boom succeeds in compiling through Firrtl.

[ccelio]

I think we can close this now. You can re-open (or make a new issue) if you’d like to catalog a desire to improve FIRRTL performance on this front.