summaryrefslogtreecommitdiff
path: root/src/qml/compiler/qv4bytecodehandler_p.h
Commit message (Collapse)AuthorAgeFilesLines
* Use SPDX license identifiersLucie Gérard2022-06-111-38/+2
| | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Pick-to: 6.4 Task-number: QTBUG-67283 Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* qml: Rename Q_QMLCOMPILER_EXPORT to Q_QML_COMPILER_EXPORTMaximilian Goldstein2022-03-241-1/+1
| | | | | | | | Otherwise we are in conflict with the export macro of the qmlcompiler library. Change-Id: Ic0f647a6708bc4c0b32ee63a684d56c4fbfca2a7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Disable copy and move operators and ctors for ByteCodeHandlerUlf Hermann2021-07-051-0/+2
| | | | | | | You should really not copy or move it around. Change-Id: I8137d175d63fcfeb915fb5f18e237fbd3fede67a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Export QV4::Moth::ByteCodeHandlerUlf Hermann2021-07-021-1/+3
| | | | | | | We need it in libQt6QmlCompiler. Change-Id: I0582d8fda2f8cb952f04490be86408b502a13960 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* V4: Add reset() method to the byte code handlerUlf Hermann2020-12-041-0/+1
| | | | | | | | This is necessary if you want to parse the same byte code in multiple passes. Change-Id: I8d3e9739b7cb3682d0f1d26e675ead8b7ce66a93 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* V4: Change ByteCodeHandler::startInstruction to return an enumErik Verbruggen2019-02-011-1/+2
| | | | | | | | | | | If ProcessInstruction is returned, the generate_* function and endInstruction will be called. If SkipInstruction is returned, they won't be called. This can be used by subclasses that can detect dead code, to suppress handling that code. Change-Id: I3b4a8eebb5701f287c8199bd40bc63fe04a35007 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* V4: Move relative-to-absolute offset calculation to base classErik Verbruggen2019-01-311-0/+2
| | | | | | | Now other subclasses of the BytecodeHandler can also use the method. Change-Id: Ib1a19e5ef6beb6c62b6a0214a6658f57b7e74a1a Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* V4: Generate labels for backward jumpsErik Verbruggen2019-01-311-2/+0
| | | | | | | | | | | | | | | | | | | | | | | When analyzing the bytecode from top-to-bottom in a single pass, we don't know when a jump back to previously seen code occurs. For example, in the baseline JIT we would already have generated code for some bytecode when we see a jump back (like at the end of a loop body), and we can't go back and insert a label to jump to. As JavaScript has no goto's, the only backward jumps are at the end of loops, so there are very few cases where we need to actually generate labels. This was previously handled by analyzing the bytecode twice: once to collect all jump targets, and then second pass over the bytecode to do the actual JITting (which would use the jump targets to insert labels). We can now do that with one single pass. So the trade-off is to store 4 bytes more per function plus 4 bytes for each loop, instead of having to analyze all functions only to find where all jumps are each time that function is JITted. Change-Id: I3abfcb69f65851a397dbd4a9762ea5e9e57495f6 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* V4: Collect trace information in the interpreterErik Verbruggen2019-01-251-0/+6
| | | | | | | | | | | | | | | Collect type information about values used in a function. These include all parameters, and the results of many bytecode instructions. For array loads/stores, it also tracks if the access is in-bounds of a SimpleArrayData. Collection is only enabled when the qml-tracing feature is turned on while configuring. In subsequent patches this is used to generated optimized JITted code. Change-Id: I63985c334c3fdc55fca7fb4addfe3e535989aac5 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* V4: clarify current vs. next instruction offset in ByteCodeHandlerErik Verbruggen2018-08-201-2/+4
| | | | | | | | | | | | | | | When executing an interpreter instruction, the code pointer points to the next instruction. However, sometimes a pointer to the current instruction is needed. That was hacked-around by having startInstruction be called before updating the pointer. This is confusing and leads to unexpected off-by-one-instruction cases. So now during startInstruction calls and generate_instructionName calls, there is a currentInstructionOffset() and a nextInstructionOffset() that do what's on the tin in both places. Change-Id: Ie8dd35ff0a7d236f008030ef4c29ec3f31c07349 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Move bytecode handler into a separate file, so it can be re-usedErik Verbruggen2018-05-281-0/+113
Change-Id: I11721025fd3df5efbcc6f6c8cb31fa2f89ead03f Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
View Lorry Controller Status