Conversation
83be14a to
c22d88e
Compare
Codecov Report
@@ Coverage Diff @@
## master #403 +/- ##
==========================================
- Coverage 99.35% 99.18% -0.17%
==========================================
Files 49 50 +1
Lines 13242 13801 +559
==========================================
+ Hits 13156 13689 +533
- Misses 86 112 +26 |
c22d88e to
e29870a
Compare
|
|
||
| const auto [code, pos2] = | ||
| parse_expr(pos1, end, static_cast<uint32_t>(local_count), func_idx, module); | ||
| // TODO: Clarify in spec what happens if count of locals and arguments exceed uint32_t::max() |
There was a problem hiding this comment.
I'm moving this assertion from parse_expr to parse_code, because now parser_expr doesn't get local_count and iterates locals_vec anyway on each local access, to find the type.
e29870a to
4d3e011
Compare
159edef to
01b99cc
Compare
lib/fizzy/instructions.hpp
Outdated
|
|
||
| struct InstructionType | ||
| { | ||
| std::initializer_list<ValType> inputs; |
There was a problem hiding this comment.
I'm still not sure whether it's valid to use initializer_list like this.
Declaring constexpr initalizer_list object works only if it's static local or global, but doesn't compile if it's auto https://godbolt.org/z/iWUg6B
The discussions that I found are not very clear to me, but seem to come to the conclusion that standard doesn't guarantee it to be valid.
https://stackoverflow.com/questions/16063123/is-it-legal-to-declare-a-constexpr-initializer-list-object
https://stackoverflow.com/questions/27496004/why-isnt-stdinitializer-list-defined-as-a-literal-type
There was a problem hiding this comment.
Just learned that in C++20 std::vector can be constexpr, that would help a lot.
There was a problem hiding this comment.
Found relatively simple solution with a custom struct instead of initializer_list, pushing it as a separate commit for now.
There was a problem hiding this comment.
Just learned that in C++20
std::vectorcan beconstexpr, that would help a lot.
I don't think it would help. It is constexpr because you can use new and delete in constexpr evaluation (consteval), but for initialization dynamic memory allocation would be needed, so compilation would probably fail. See also constinit.
48ce911 to
aba60a0
Compare
aba60a0 to
baa2d62
Compare
baa2d62 to
a6f705c
Compare
f6be8d7 to
1a1b8be
Compare
|
Rebased and squashed |
chfast
left a comment
There was a problem hiding this comment.
Looks good, but let's keep in mind the performance regression.
|
I'm getting somewhat less of regression on my laptop |
| /* block = 0x02 */ {{}, {}}, | ||
| /* loop = 0x03 */ {{}, {}}, | ||
| /* if_ = 0x04 */ {{ValType::i32}, {}}, | ||
| /* else_ = 0x05 */ {{}, {}}, |
There was a problem hiding this comment.
Why have these initialisers {{}, {}}, when empty opcodes can go with {} ?
There was a problem hiding this comment.
It can, I just found it somewhat more explicit to show both input and output empty. Would you prefer to make it {}?
There was a problem hiding this comment.
It doesn't really make any difference.
| { | ||
| std::optional<ValType> type; | ||
| std::tie(type, pos) = parse_blocktype(pos, end); | ||
| std::optional<ValType> block_type; |
There was a problem hiding this comment.
Why do you need this refactoring btw?
There was a problem hiding this comment.
type would shadow the new variable in the outer scope (which I called types originally, but @chfast suggested to rename)
7d2c6c3 to
3adfb02
Compare
lib/fizzy/parser_expr.cpp
Outdated
| auto& frame = control_stack.top(); | ||
| const auto& metrics = metrics_table[opcode]; | ||
| const auto metrics = metrics_table[opcode]; | ||
| const auto type = type_table[opcode]; |
There was a problem hiding this comment.
Are these two becoming a copy now and not a reference?
There was a problem hiding this comment.
This is a mistake I think, will make them references.
3adfb02 to
0d30b02
Compare
Co-authored-by: Andrei Maiboroda <andrei@ethereum.org>
Co-authored-by: Andrei Maiboroda <andrei@ethereum.org>
0d30b02 to
7beb186
Compare
No description provided.