Details
-
User Story
-
Resolution: Unresolved
-
P2: Important
-
6.2, 6.x
Description
A while back I was writing the following in the internal communication channel (guessing it's time to formulate that as a task for future):
Going forward with compiling QML to C++, does it make sense to invest into C++ IR and optimizations on it? From the qmltc code generator stand point, I'm doing quite a lot of irrelevant heavy-lifting:
- There are numerous cases where I must generate code which re-uses a particular variable:
- List property assignments (which are pretty common in object bindings), have to fetch the property only once if that property is the same (otherwise there's a huge overhead since we have to use QQmlListReference)
- Group property / attached property assignments: usually come in bulk and also benefit a lot from just calling a read/write function once (I think I ignore this problem in attached properties case for now though)
- Connecting alias notify to origin property notify has to fetch the outer context of "this". That could also be optimized (e.g. fetch the context only once). Albeit this is something that C++ compiler should handle - the context accessing code is all in the headers. (but I'll still need to give it a second look)
- There are cases where I could remove certain code straight away
- Value type group properties are very-very special, since they need "read" in the beginning and "write" in the end. Yet, if the only thing we do is "assign script bindings", there's no point in calling read/write at all (since the binding doesn't use the group property value)
The cases above is something from the top of my head. The overall problem is that C++ compiler wouldn't even try to optimize certain calls I think (if the function definition is not visible immediately, the compiler has to assume it can cause side effects, right? - albeit maybe const-qualifier helps - and then generate multiple calls). From the qmltc/qmlsc standpoint, we know that e.g. "fetch property" done multiple times (without writes in-between) is safe to be done only once -> we can optimize that, C++ compiler might not.
So my point is: we should probably (at some point at least) have a C++ IR format both for qmltc and qmlsc that can be used to perform QML/QMetaObject-specific code optimizations.
Right now I can keep up with the stuff in the code generator itself (by doing checks like "if variable already created, reuse it"), but I'm not sure whether that'll go out of hand quickly. Anyhow, I don't have enough justification to work on it at the moment.
Pros of having C++ IR/optimizations:
- simpler code generation (actually it'll be standardized by the IR api)
- potential to streamline code dumping (IR would probably be directly serialized into strings -> dead simple C++ source code creation is included)
Cons:
- quite a lot of time spent on developing the IR + optimizer (infra, implementation, etc.)
Attachments
Issue Links
- relates to
-
QTBUG-105538 qmltc evolution collection task
- Open