You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Once #300 is merged, the default way to call a component will be the invoke statement. Once that is the case, we can change the ir::Builder so that it doesn't automatically add go/done ports to components (and move that functionality to component-interface pass).
Actually, I think the stuff above is irrelevant to deprecating accessing to the component go/done signal usage. Once #712 is merged, any group computation performed by a group using the a component's go/done interface can be rewritten using invoke-with.
I don't think there is any harm in keeping access to primitive's go/done ports either. Maybe we should remove this issue in lieu of having explicit go/done ports on all components.
Without thinking about it too hard, I'm inclined to agree? (That is, that there is no harm in keeping explicit access around & possible, especially if we require all components to have such ports.) It seems like this explicit access would nicely provide a "compile target" for invoke if I'm not mistaken, right?
Once #300 is merged, the default way to call a component will be the
invoke
statement. Once that is the case, we can change the ir::Builder so that it doesn't automatically addgo
/done
ports to components (and move that functionality tocomponent-interface
pass).Few things that rely on this interface:
mult_pipe
in the default PE. Removable after Make primitives use invokable go-done interface #331).sqrt
andmult_pipe
(requires Make primitives use invokable go-done interface #331).The text was updated successfully, but these errors were encountered: