llvm / llvm/circt

[HW] TypeAliasType should reference a declaration, instead of keeping the inner type duplicated

Open
#1,642 1 comment 0 reactions 0 assignees View on GitHub
help wanted HW
Dominant language
C++
Stars
2.2k
Forks
524
Avg merge
3d 2h
Merged PRs (30d)
46

Description

This is the main unresolved TODO related to the efforts to support type declarations in CIRCT. We have a type called `hw.typealias`, which holds a symbolic reference to a `hw.typedecl` operation. However, during parsing, we may need to know about the referenced type, and don't seem to have a way to access it. This caused us to resort to duplicating the referenced type in the `hw.typealias`, which is really bad!

For example, if there is a declaration of `@__hw_typedecls::@foo`, which declares `@foo` to be of type `i1`, we'd have to have this type in the IR:

```mlir
!hw.typealias<@__hw_typedecls::@foo, i1>,
```

We should figure out a way to drop that. It was discussed in a past MLIR ODM: https://www.youtube.com/watch?v=hqcM6fJWntM.

If I'm recalling correctly, a couple options have been discussed:

* Expose the OpBuilder through the Parser, and dig around in its insertion block to look for the declaration
* Expose a method on the Parser along the lines of "lookup a symbol you've already parsed"

I started looking into the first one once, but didn't make any definitive headway. I'm opening this issue it isn't forgotten.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by examining the CIRCT HW typealias and typedecl parsing paths, then review the linked MLIR ODM discussion and the two parser-lookup approaches described in the issue. Done means hw.typealias can reference the declaration without duplicating the inner type while still resolving the referenced type during parsing.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
compilers
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.