Skip to content

Minimum viable type validation#403

Merged
gumb0 merged 15 commits intomasterfrom
validate-types-no-block-br
Jul 17, 2020
Merged

Minimum viable type validation#403
gumb0 merged 15 commits intomasterfrom
validate-types-no-block-br

Conversation

@gumb0
Copy link
Collaborator

@gumb0 gumb0 commented Jul 1, 2020

No description provided.

@gumb0 gumb0 force-pushed the validate-types-no-block-br branch 3 times, most recently from 83be14a to c22d88e Compare July 2, 2020 09:46
@codecov
Copy link

codecov bot commented Jul 2, 2020

Codecov Report

Merging #403 into master will decrease coverage by 0.16%.
The diff coverage is 96.05%.

@@            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     

@gumb0 gumb0 force-pushed the validate-types-no-block-br branch from c22d88e to e29870a Compare July 2, 2020 10:26

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()
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@gumb0 gumb0 force-pushed the validate-types-no-block-br branch from e29870a to 4d3e011 Compare July 2, 2020 11:19
@gumb0 gumb0 force-pushed the validate-types-no-block-br branch 6 times, most recently from 159edef to 01b99cc Compare July 2, 2020 16:27
@gumb0 gumb0 marked this pull request as ready for review July 2, 2020 16:51

struct InstructionType
{
std::initializer_list<ValType> inputs;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator Author

@gumb0 gumb0 Jul 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just learned that in C++20 std::vector can be constexpr, that would help a lot.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found relatively simple solution with a custom struct instead of initializer_list, pushing it as a separate commit for now.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just learned that in C++20 std::vector can be constexpr, 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.

@gumb0 gumb0 force-pushed the validate-types-no-block-br branch from 48ce911 to aba60a0 Compare July 3, 2020 13:41
@gumb0 gumb0 requested review from axic and chfast July 3, 2020 13:50
@chfast chfast force-pushed the validate-types-no-block-br branch from aba60a0 to baa2d62 Compare July 6, 2020 08:41
@chfast chfast mentioned this pull request Jul 6, 2020
@chfast chfast force-pushed the validate-types-no-block-br branch from baa2d62 to a6f705c Compare July 6, 2020 09:41
@gumb0 gumb0 force-pushed the validate-types-no-block-br branch 4 times, most recently from f6be8d7 to 1a1b8be Compare July 7, 2020 09:37
@gumb0
Copy link
Collaborator Author

gumb0 commented Jul 7, 2020

Rebased and squashed span-related and constexpr_array commits.

@gumb0 gumb0 requested a review from chfast July 10, 2020 11:11
Copy link
Collaborator

@chfast chfast left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, but let's keep in mind the performance regression.

@gumb0
Copy link
Collaborator Author

gumb0 commented Jul 10, 2020

I'm getting somewhat less of regression on my laptop

fizzy/parse/blake2b_mean                                +0.2133         +0.2153            41            50            41            50
fizzy/parse/ecpairing_mean                              +0.3124         +0.3131          2191          2876          2190          2876
fizzy/parse/keccak256_mean                              +0.2555         +0.2565            73            92            73            92
fizzy/parse/memset_mean                                 +0.1513         +0.1517            10            12            10            12
fizzy/parse/mul256_opt0_mean                            +0.2082         +0.2086            13            15            13            15
fizzy/parse/sha1_mean                                   +0.2586         +0.2587            65            82            65            82
fizzy/parse/sha256_mean                                 +0.2389         +0.2391           112           138           112           138
fizzy/parse/micro/eli_interpreter_mean                  +0.1198         +0.1205             7             8             7             8
fizzy/parse/micro/factorial_mean                        +0.1289         +0.1289             2             2             2             2
fizzy/parse/micro/fibonacci_mean                        +0.1435         +0.1435             2             2             2             2
fizzy/parse/micro/host_adler32_mean                     +0.0668         +0.0669             3             3             3             3
fizzy/parse/micro/spinner_mean                          +0.0921         +0.0922             2             2             2             2

/* block = 0x02 */ {{}, {}},
/* loop = 0x03 */ {{}, {}},
/* if_ = 0x04 */ {{ValType::i32}, {}},
/* else_ = 0x05 */ {{}, {}},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why have these initialisers {{}, {}}, when empty opcodes can go with {} ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can, I just found it somewhat more explicit to show both input and output empty. Would you prefer to make it {}?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't really make any difference.

{
std::optional<ValType> type;
std::tie(type, pos) = parse_blocktype(pos, end);
std::optional<ValType> block_type;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need this refactoring btw?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

type would shadow the new variable in the outer scope (which I called types originally, but @chfast suggested to rename)

@axic axic force-pushed the validate-types-no-block-br branch 3 times, most recently from 7d2c6c3 to 3adfb02 Compare July 16, 2020 16:02
auto& frame = control_stack.top();
const auto& metrics = metrics_table[opcode];
const auto metrics = metrics_table[opcode];
const auto type = type_table[opcode];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these two becoming a copy now and not a reference?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a mistake I think, will make them references.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@gumb0 gumb0 force-pushed the validate-types-no-block-br branch from 3adfb02 to 0d30b02 Compare July 16, 2020 16:23
@gumb0 gumb0 requested a review from axic July 16, 2020 16:32
@gumb0 gumb0 force-pushed the validate-types-no-block-br branch from 0d30b02 to 7beb186 Compare July 17, 2020 10:06
@gumb0 gumb0 merged commit ee1f21d into master Jul 17, 2020
@gumb0 gumb0 deleted the validate-types-no-block-br branch July 17, 2020 10:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants