Details

    • Technical task
    • Resolution: Fixed
    • P2: Important
    • 6.7.0 FF
    • QML: Compiler
    • None
    • 72e9f4752 (dev), c86c13d49 (dev), bd9a8eb6d (dev), 1e9d89e29 (dev), ede3389a3 (dev), eaf1f0efe (dev)

    Description

      Now that we have defined semantics for write-back and read-back we should be able to implement it in at least some cases, using the original lookups. This will enable a large amount of additional code to be compiled to C++: setting value type or sequence properties procedurally.

      A few observations:

      1. We only want write-back where it's safe from read-back. An earlier approximation was "in the same statement", but "while not affected by side effects" seems better overall (especially since we analyze potential side effects already).
      2. We can have chained write-backs.
      3. The original object we want to write back to may have been deleted. In fact there are other places where this might get in the way. We actually need to check whether an object may be affected by side effects when interacting with it in any way. If so, we need to guard it using something like QPointer or QV4QPointer. On the flip side, if nothing is affected by side effects, we should be fine, also on write-back.
      4. Ideally we should sort out our registers so that no register that was the base of a lookup before is ever re-used. Then we can store the register name of the lookup base in the QQmlJSRegisterContent and write back to it. Such an invariant is hard to guarantee, though. Imagine a loop that always overwrites the base but only sometimes performs a lookup on the base.
      5. A less ideal solution would be to produce extra variables for each pair of base and write back. Those would get populated with the base at the time of the lookup and eventually used for the write back. Copies of value types can be expensive, though.
      6. Can we detect whether the original register is still fine?

      One way to deal with this would be a copy-on-write mechanism for registers. If we do a lookup, the resulting value "registers" itself with the base of the lookup. If the base gets overwritten while a dependent value is "registered", we copy the base and use the copy for any write-back. When the dependent value is destroyed we drop the copy and "unregister".

      This is all way too complicated. Rather:

      1. If the lookup and the write-back are in the same basic block and the value written back cannot be affected by side effects, we can be sure the base is still fine. No need to do any copy-on-write. The only problem may be that the base register may have been re-used for something else. That should be detectable, though. We can grant ourselves another register variable in such a case.
      2. Anything else shall be rejected

      This allows all the desirable "simple" write backs. Plus some, as you can artfully concoct a very long basic block without side effects. However, the rule is easy to explain: no branches and joins, no function calls, and no setting of other properties between a lookup and its write back.

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          People

            ulherman Ulf Hermann
            ulherman Ulf Hermann
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: