Fix issue where reify would do the same lookup twice

[jackkoenig]

This is not a functional bug. The recursive form of reify for Element would use the .topBinding from the wrong argument, so it would recurse an extra time, but it would ultimately converge to the right value.

This is really subtle and I don't think it's even possible to write a test for it (other than by adding a side effect to reify but that would be insane).

It is a very slight, probably unmeasurable, performance improvement.

The way I convinced myself that the problem happened and was fixed was with the following example code:

import chisel3._
import chisel3.experimental.dataview._
import circt.stage.ChiselStage

class Foo(val foo: UInt) extends Bundle
class Bar(val bar: UInt) extends Bundle

object Views {
  implicit val foo2bar = DataView[Foo, Bar](f => new Bar(f.foo.cloneType), _.foo -> _.bar)
}
import Views._

class MyModule extends Module {
  val a = IO(Input(new Foo(UInt(8.W))))
  val z = IO(Output(new Bar(UInt(8.W))))
  z := a.viewAs[Bar]
}

object Main extends App {
  val chirrtl = ChiselStage.emitCHIRRTL(new MyModule)
  println(chirrtl)
}

then add println(s"reify on $elt") as the first statement in the fixed function you'll see:

[info] reify on MyModule.z.bar: IO[UInt<8>]
[info] reify on _$$View$$_.z_view.bar: [UInt<8>]
[info] reify on MyModule.a.foo: IO[UInt<8>]
[info] reify on MyModule.a.foo: IO[UInt<8>]

You can see a little double reify there, with this fix you get:

[info] reify on MyModule.z.bar: IO[UInt<8>]
[info] reify on _$$View$$_.z_view.bar: [UInt<8>]
[info] reify on MyModule.a.foo: IO[UInt<8>]

Contributor Checklist

• Did you add Scaladoc to every public function/method?
• Did you add at least one test demonstrating the PR?
• Did you delete any extraneous printlns/debugging code?
• Did you specify the type of improvement?
• Did you add appropriate documentation in docs/src?
• Did you request a desired merge strategy?
• Did you add text to be included in the Release Notes for this change?

Type of Improvement

• Performance improvement

Desired Merge Strategy

• Squash

Release Notes

Reviewer Checklist (only modified by reviewer)

• Did you add the appropriate labels? (Select the most appropriate one based on the "Type of Improvement")
• Did you mark the proper milestone (Bug fix: 3.5.x or 3.6.x depending on impact, API modification or big change: 5.0.0)?
• Did you review?
• Did you check whether all relevant Contributor checkboxes have been checked?
• Did you do one of the following when ready to merge:
  • Squash: You/ the contributor Enable auto-merge (squash), clean up the commit message, and label with Please Merge.
  • Merge: Ensure that contributor has cleaned up their commit history, then merge with Create a merge commit.

[seldridge]

I don't 💯 follow this, but the difference in the test case LGTM. Nice find.