> ok for A1 i'm good with named phases and we can modify as necessary. i think
> the A2.2 solution of directly registering target attrs makes sense to me. is
> that the direction we're aligned on here?
we can discuss this next week at the community meeting, or if we're in
alignment on these two
Thanks @mbs-octoml for this detailed explanation. Being a Collage-supported
backend is definitely something we want to achieve for UMA-integrated backends.
> The registration of patterns will need to support the existing triple of
> (pattern name, pattern, predicate) since the predicates are nec
> This aligns with A2.2 -- directly registering each attribute.
@manupa-arm Then just for clarification a few questions because I might have
misunderstood your initial idea. For A2.1 you were thinking about registering
an attribute preprocessor to the target
`Target().add_attrs_preprocessor(Pre
So here is my take on A2:
In the accelerator-specific backend, a user would register target attribute
names e.g.
```
class UltraTrailBackend(UMABackend):
def __init__(self):
super(UltraTrailBackend, self).__init__()
Thank you @manupa-arm for this input! I'll go over the points in more detail in
the next few days.
For A1,
I agree, that enums are generally a cleaner solution. We stuck with ints until
now because of the the following two reasons:
- Phases for TIR passes are currently also int-based
- For some
