It'd be neat if we could magically set this to the pass name, as that's usually what we want!

Ugh... this has annoyed me for a while. There's no nice char * readily available. However, I did find a way to do it that looks fine. See what you think about: 4ab6d85

I have questions about domains and classes and names -- you probably can guess, the usual kind.

Modulo making domains classlike, insofar as classes are nominally typed it may be important to give consideration here. Probably the associations class is the main question (the other will continue as a domain (?) or at least can re-use the class name, assuming running with same namespace for them), while it's squarely compiler-generated it needs to be the same across SC units.

Something to think about.

Yeah, good point. The re-use of the existing domain name for the "input" class works. The output class will need to have an ABI-determined name. While I think it's probably fine to keep this as <name>_out for now, this should likely be something better like <name>$domainOut. Or: something that uses $ to prevent collision and is impossible to collide with. Same thing for the port name.

I won't treat this as blocking.

Does this pass have any prerequisites? Should these be stated, and can/should they be checked for?
Having neither seems dangerous, but I'm not sure sure what that might entail.

This maybe needs InferDomains to have run (or be equivalent to having run already, maybe, if input is already fully set)? Where in the pipeline is this expected to live -- hopefully part of the overall LowerToHW pipeline (which includes LowerClasses)?

I know there's advice going around (super fair characterization follows!) that passes should yolo their way and crash on folks not swoll enough to use them "properly" but that's basically the same argument against defensive assertions that also is contrary to LLVM ethos and building quality products; if one piece of advice is blindly taken I'd much rather have a compiler (and especially be on a compiler team that works towards) that works every time over ... I'll spare my critique of one blindly following the other way 👍. Of course there are trade-offs and consideration of best engineering best practices at play here... not everything can or should check everything, so on.

Use your judgement, as I'm sure you would regardless 😁 .

Making passes that don't have silent assumptions they crash on really helps a compiler project overall, and is part of being a high-quality pass in general. Pipeline debugging (bugpoint-style), reductions (circt-reduce style), pass rearranging, so on.

Anyway 😄 . I'm not sure this needed so many words, please do what you think is best here 👍 .

I'm honestly partly sincerely interested in what this needs for it to work! So if nothing else please spare words to answer that for me if you would.

Known prerequisites: this needs to run after infer domains (which is WIP right now) and before lower classes. If run before infer domains, it won't crash or anything like that, but it will produce incomplete results that differ from what would happen if run after infer domains. E.g., if association information is missing, then it will claim that those ports have no associations.

The current limitations of the representation of domains (that ports are either domain ports or have associations) means that this assumes a post-LOA representation. However, there is no way to actually represent this pre-LOA right now. The pass doesn't require LowerTypes currently, though that is again due to the lack of the ability to have associations on fields. Once per-field associations are available, the pass will need an update.

Clearly, as the representational restrictions are lifted, the pass will need to gain capabilities.

Yes, the pass is expected to be in the LowerToHW pipeline. This adds a lot of distinct attr annotations to ports which will have a detrimental effect to the ability of the module to be optimized. For that reason it needs to be as late as possible.

1d3f95a adds top-level commentary summarizing the above comment.

Until we have our domain define connectlike (#9067) maybe this is moot, but....

What drives the added object of type (1) that are now input ports?

Conceptually, I mean, if nothing else. In some cases this can be from the parent's input domain port. When local to a module (whatever "allocate a domain" looks like), it's from that point I'd imagine.

This brings us to the example I was bringing up the other day on this subject re:proposed lowering and asymmetric handling of input/output domain information.

Basically, I'd expect the lowered domain plumbing to mirror that of the domain connections originally:
If a domain input port is (in the FIRRTL) driven by a sibling's output port, where does the domain object of type (1) come from?

By lowering (2) to associations.. ah, there it is.
Okay so they're both (at least) objects of type (1), (2) additionally includes a list of association paths.

So presumably the answer to this question is that we'd grab the domain object out of the output of type (2) from the sibling instance and drive that to the input port (now expecting something of type (1)).

Okay so -- just how I like thinking about these things:

1. All domain values and connectivity become type (1) and propassign instead of domain define.
2. Output ports have association information bundled into the required-for-correctness-of-IR threading of type (1) objects (lowered domain values) which implicitly also ties the two together for easy processing agnostic of knowledge of, say, domain port names.

Anyway this breakdown isn't how the code does things, and that's all good, but hopefully you follow. We transform domains to classes, and replace values with objects of that class, and connectivity is basically the same throughout. For output ports we instead drive into the associations object (and grab it back out as needed).

Does this make sense, anything wrong/missing here?
Thanks!

Yeah, this is correct. The lowered class plumbing will mirror that of the original domain plumbing. Things may get optimized, though. Also, aliasing is possible (but not problematic).

Aliasing Example

Consider the following two circuits. The first has two output aliased domains of A:

domain ClockDomain:
  input name_in: String
  output name_out: String

  propassign name_out, name_in

module Foo:
  input A: Domain of ClockDomain
  output B: Domain of ClockDomain
  output C: Domain of ClockDomain
  output a: UInt<1> domains [A]
  output b: UInt<1> domains [B]
  output c: UInt<1> domains [C]

  invalidate a
  invalidate b
  invalidate c
  
  domain_define B = A
  domain_define C = A

domain ClockDomain:
  input name_in: String
  output name_out: String

  propassign name_out, name_in

module Foo:
  input A: Domain of ClockDomain
  output a: UInt<1> domains [A]
  output b: UInt<1> domains [A]
  output c: UInt<1> domains [A]

  invalidate a
  invalidate b
  invalidate c

When this eventually hits the OM APIs in the final MLIR, the shape of the module Foo will look different for the first circuit and for the second. In the first, the user will have to provide a single clock domain object, setting the name_in parameter. They will then get three domains out, each associated with one port. However, the user will need to recognize that all of these are aliases as they have the same name.

There is no aliasing in the latter.

If this is an internal module, it is reasonable that the first module is optimized into the second. If this is a public module, then (I think) it cannot be optimized and it's up to the user to deal with the aliasing.

Thank you! This makes sense. I was wondering how much inspect-what-is-there will be done in the consuming API's. I'm a little surprised we're on board with having the set of domain association objects being dependent on optimizations, but that almost takes us to point of preserving a module just to run a property out that says the domain has no associations.

OTOH since we're not splitting these apart at the MLIR level we could gather associations at the top of public modules (like OMIR would do for children nodes, IIRC?).
Nevermind that, mostly, for now 😄 .

That does raise question of how the API's might reason about domains they are provided associations for that they don't know the origin of (similarly but slightly less obvious than needing to provide information for domains not originally part of the module's interface).

I'll move this conversion to a chat 👍 .

Do we usually reuse distinctattr's? I don't think so, but not sure that that is important. Do you know/remember @youngar ?

Talked with Andrew about this offline and, while we don't seem to do this currently, there should be no problem with it.

Thank you! This makes sense. I was wondering how much inspect-what-is-there will be done in the consuming API's. I'm a little surprised we're on board with having the set of domain association objects being dependent on optimizations, but that almost takes us to point of preserving a module just to run a property out that says the domain has no associations.

OTOH since we're not splitting these apart at the MLIR level we could gather associations at the top of public modules (like OMIR would do for children nodes, IIRC?).
Nevermind that, mostly, for now 😄 .

That does raise question of how the API's might reason about domains they are provided associations for that they don't know the origin of (similarly but slightly less obvious than needing to provide information for domains not originally part of the module's interface).

I'll move this conversion to a chat 👍 .