[External functions] Updated the external function feature

[Carmine50]

In this new pull request there are 3 important modifications to the external function feature:

• The results of the external function are removed if the external function's results are not used inside the function.

• The names of the ports of the top function generated with the external function respect the function's name declared in the c source code. It is not possible anymore to instantiate the same function twice.

• There is a new benchmark added to the integration test external_integration that can be used to test this functionality.

[Jiahui17]

Hi Carmine thank you for fixing this! I have two questions about the design choices (also see the review above):

• It is not possible to instantiate function twice: what if we want to call the same external function twice?
• Remove unused results of the external function: Do you think doing this optimization will make the backend's job harder? The external function's interface is well-defined (i.e., given by the function's prototype), but we ignore a port here before going into the backend.

[Carmine50]

Hello @Jiahui17 , here are my answers to your questions:

1. An external function represents a specific set of ports. The instantiation of a function represents the presence of this set of ports. By definition, you cannot have 2 sets of ports with the same name. Since this feature enables the user to specify the set of ports, the user should also decide different names for 2 sets of ports.

2. The backend job would be unchanged. Removing the unused results only means removing unused ports. The job of the backend would not change.

[lucas-rami]

I am ok with the policy of only being able to invoke an external function once because it is inconvenient to derive unique port names for all invocations.

However, I do not think that dynamically removing ports for unused results of the internal function call is a good design decision. It ties the interface of the circuit we generate with the details of the internal circuit architecture, while the two should be as independent as possible. Additionally, this creates an inconsistency with how we handle "normal function arguments"; even if they are not used inside the function, we still instantiate ports for them as if they were used. That way, when one looks at a function's declaration, one can know for sure what the interface will look like for "normal function arguments", irrespective of the function's definition. Finally, if we start removing ports when they are not used, it makes it much harder for someone iterating on a kernel's implementation to interface programmatically with the circuit we generate; they may make a temporary change in the kernel implementation that renders an argument unused, and suddenly their wrapper circuit no longer works because it references ports of the Dynamatic circuits that are no longer generated.

[Carmine50]

Hey @lucas-rami ,

Related to your second point, yes it makes sense. I will revert those changes accordingly.

[Carmine50]

Yes sorry, I pushed the wrong file. I made the correct changes. Anyway, I changed the SmallVector sizes because the compiler would give me an error for inconsistent return type. I pushed it by mistake. Thank you :)