Is the Base Profile really the base of all profiles?

[LaurentAjdnik]

And what does it mean exactly?

Does it define a set of requirements that have to be met by all other profiles?

Does it define a set of restrictions that will also be forbidden to all other profiles?

Is it a mix of both?

In any case, how to tune how far we can go without hindering the writing of future profiles?

Can we already foresee profiles that will have such drastically different approaches/paradigms that they could not "inherit" from the Base Profile?

[chemix-lunacy]

I don't really have a strong opinion here since the current approach is fine and if issues come up later it's easy enough to switch to an alternative, but I'll write my thoughts out if it helps things. From my point of view it's purely about us not knowing what people may come up with, or what will win our conceptually in the future, so saying that 'everything' has to inherit off the base profile is pretty limiting and makes writing future profiles more complicated.

An immediate example is the base profile not allowing variables, must have one method which one basic block, which is also the special entry-point method, that in future profiles should only have very particular syntax and calls in it. Most of these rules will immediately change or become void in future profiles. While we can very much write the profile in a way which states that these constraints only apply to this profile, I just feel the web of rules and edge-cases about what applies where is going to become unncessarily complicated in both reading and application as time goes on.

An alternative approach I like is composable profiles. Profiles would be simply viewed as small collections of supported features or constraints, so the base profile as-written would be composed of the 'core entry-point' profile, 'core rotations', 'single entry-point' profile and little specific-to-that-profile rules. First 2 being declarations of features, the latter being specific constraints. It means you can mix-and-match rules and features based on the specific requirement for whatever your code or backend is doing. More complicated in some ways, but also more flexible and unambiguous in its rules. It has its own problems but I prefer the trade-offs.

I also personally feel we're almost garanteed reach a point where we want / have QIR profiles that are distinctly seperate from everything that came before: circuit vs pulses vs super low-level hw instructions vs fun new higher-than-circuit model; digital vs analogue vs other; etc. But even if this does happen it's pretty far in the future.

[LaurentAjdnik]

Thanks @chemix-lunacy for your feedback!

An alternative approach I like is composable profiles. Profiles would be simply viewed as small collections of supported features or constraints. [...] It means you can mix-and-match rules and features based on the specific requirement for whatever your code or backend is doing.

Love it! I was reaching a similar conclusion when we started discussing backends but I didn't have time to share it during our last meeting.

This modularity would also improve consistency between profiles. They would not have to redefine/rewrite plenty of things. They could just refer to which behavior(s)/feature(s) they need. These transversal concepts would be defined once with all corresponding requirements/consequences and then re-used.

But even if this does happen it's pretty far in the future.

Still, maybe we'll need this level of modularity as soon as we start working on the next profile in line. 😉

[bettinaheim]

An immediate example is the base profile not allowing variables, must have one method which one basic block, which is also the special entry-point method, that in future profiles should only have very particular syntax and calls in it. Most of these rules will immediately change or become void in future profiles. While we can very much write the profile in a way which states that these constraints only apply to this profile, I just feel the web of rules and edge-cases about what applies where is going to become unnecessarily complicated in both reading and application as time goes on.

I think this is a phrasing problem - i.e. a challenge for writing a comprehensive spec - more than an actual issue. The goal is that a base profile compliant program also meets the specification of all other profiles. I think this is an important and worthwhile goal to ensure that it is possible at all to define portable code, and I believe the goal is achievable. I'd be happy to revise that assessment and the goal for the base profile in the future (or now) if there is a compelling argument to do so, but so far, I don't think we have a clear one just yet (thought the considerations around analogue devices may bring us there). Portable code to me is particularly compelling when it comes to actually building an ecosystem of libraries. While my goal would be for libraries to be untargeted and thus effectively compiled into the "full QIR", the QIR spec needs to give guidance on how to ensure that subsequent compilation stages can successfully target it to a certain profile. It is then up to the language frontend to define a feature set that will not require backend support beyond what the base profile requires. Even though the compiled library itself does hence not follow profile specification, it can follow the guidance in the QIR spec to ensure that it can be compiled into the Base Profile and thus - if we stick with the Base Profile being "the base of all profiles" - any other profile as needed.

An alternative approach I like is composable profiles. Profiles would be simply viewed as small collections of supported features or constraints, so the base profile as-written would be composed of the 'core entry-point' profile, 'core rotations', 'single entry-point' profile and little specific-to-that-profile rules. First 2 being declarations of features, the latter being specific constraints. It means you can mix-and-match rules and features based on the specific requirement for whatever your code or backend is doing. More complicated in some ways, but also more flexible and unambiguous in its rules.

I think a feature-based description is an excellent way of going about it at the language/frontend level. However, I am not yet sure whether that could work well for the IR spec. To be useful, a profile spec needs to give a very clear definition of what exactly the bitcode looks like and contains, whereas there is always a combination of instructions and patterns needed to fully support a specific feature. While the actual implementation this is in fact containing a (more or less experimental) setup for selecting features and restrictions, I am not sure I agree that defining the spec this way would be more unambiguous. My concern here is precisely that it is harder to make it very clear and comprehensive; a self-contained write up for each profile specifies all rules for a certain combination of available features. Certain combinations of features/restrictions may be incompatible or "work better than others", and that becomes tricky to formalize pretty quickly. Spec'ing each feature/restriction separately and allowing a profile to be an arbitrary combination of features and restrictions is extremely challenging to define well (at least if we expect a significant amount of compilation between application-level features and the "features"/capabilities of the processor itself), and starting with focusing on certain combinations rather than all combinations at once felt like a better starting point.

[bettinaheim]

Put differently: I think a feature-based specification I think is pretty ambitious to achieve at this time, since the "processor-level feature description" it needs to accurately capture the consequences of combining different application-level features (the consequences being the resulting constructs in the IR after running optimizations). Hence, I believe that a feature-based specification is likely a better fit for frontends rather than backend facing profiles. It could (should?), however, possibly be how we define the full QIR spec in the future; a profile to me can be seen as the consequences of selecting features (possibly to be defined in the full QIR spec) + applying optimizations to simplify the IR as much as possible/desirable.

To summarize, my take is that a feature-based description of profiles is feasible only if we are also ready to fully formalize a quantum processor architecture, and I think we are still quite far from being able to do that.

[chemix-lunacy]

Hence, I believe that a feature-based specification is likely a better fit for frontends rather than backend facing profiles. It could (should?), however, possibly be how we define the full QIR spec in the future; a profile to me can be seen as the consequences of selecting features (possibly to be defined in the full QIR spec) + applying optimizations to simplify the IR as much as possible/desirable.

To summarize, my take is that a feature-based description of profiles is feasible only if we are also ready to fully formalize a quantum processor architecture, and I think we are still quite far from being able to do that.

I'm cool with that, I just like being audaciously ambitious. I think the distinction between a 'front-end' and 'back-end' profile might be useful to formalize some point soon - if it hasn't been already - if we're taking the approach that the community as a whole builds the front-end compilation and optimization passes that spits out hyper optimized/specialized QIR that the various hardware providers consume.

I haven't had a chance to comb all the most recent documentation, but if that's the direction we're going I'm very much all for it.

[peter-campora]

I think that my only touchy thing with the base profile being valid code for future profiles is whether:

1. The current record functions to indicate what will be results will be the defacto way to do this going forward.
2. The current indexing scheme (i.e. 1 inttoptr ...) should be considered valid code in future profiles that can more directly represent the allocation of %Qubit* objects into variables.

Although I don't have immediate concerns supporting these going forward, it's hard to predict what will change.