Validation of instructions (plus some infra and fixes) #377

rossberg · 2023-05-14T17:16:00Z

Syntax of type definitions and validation rules for instructions, plus some adjustments for the syntax changes.

Does not yet specify how the type environment is populated with deftypes.

tlively · 2023-05-15T19:05:27Z

proposals/gc/MVP.md

-Note: Cast instructions do _not_ require the operand's source type to be a supertype of the target type. It can also be a "sibling" in the same hierarchy, i.e., they only need to have a common supertype (in practice, it is sufficient to test that both types share the same top heap type.). Allowing so is necessary to maintain subtype substitutability, i.e., the ability to maintain well-typedness when operands are replaced by subtypes.
-


Why is this no longer necessary / true / helpful?

It was primarily meant as an explanation why the earlier rules had this seemingly weird side condition about a common supertype, instead of requiring that the (explicit) target type has to be a subtype of the (implicit) source type. Since the source type is now explicit as well, and the "real" operand type no longer occurs in the rule itself (but can be weakened separately via subsumption), I though that the explanation became both confusing and unnecessary.

Fair enough. I think a call-out like this is probably still helpful since folks might not be thinking about subsumption when trying to understand the rules, but of course we cannot add an unbounded number of such helpful notes.

tlively · 2023-05-15T19:07:57Z

document/core/valid/instructions.rst

+
+* The :ref:`reference type <syntax-reftype>` :math:`\X{rt}` must be :ref:`valid <valid-reftype>`.
+
+* Then the instruction is valid with type :math:`[\X{rt}'] \to [\I32]` for any :ref:`valid <valid-reftype>` :ref:`reference type <syntax-reftype>` that :ref:`matches <match-reftype>` :math:`\X{rt}`.


Is it fine to leave it implicit that the mentioned "valid reference type that matches rt" is rt'?

Ah, no, that was a typo. Fixed.

tlively · 2023-05-15T19:25:26Z

document/core/valid/instructions.rst

+* Let :math:`t^\ast` be the concatenation of all :math:`t_i`.
+
+* Then the instruction is valid with type :math:`[t^\ast] \to [(\REF~x)]`.


Suggested change

* Let :math:`t^\ast` be the concatenation of all :math:`t_i`.

* Then the instruction is valid with type :math:`[t^\ast] \to [(\REF~x)]`.

* Then the instruction is valid with type :math:`[] \to [(\REF~x)]`.

tlively · 2023-05-15T19:30:45Z

document/core/valid/instructions.rst

+
+* Let :math:`t` be the :ref:`value type <syntax-valtype>` :math:`\unpacktype(\storagetype)`.
+
+* The extension :math:`\sx` must be present of and only if :math:`t` is different from :math:`\storagetype`.


Suggested change

* The extension :math:`\sx` must be present of and only if :math:`t` is different from :math:`\storagetype`.

* The extension :math:`\sx` must be present if and only if :math:`t` is different from :math:`\storagetype`.

Why spec this condition as opposed to "if and only if :math:\storagetype is i8 or i16"? The latter seems more straightforward.

Fair enough, changed.

tlively · 2023-05-15T19:31:02Z

document/core/valid/instructions.rst

+
+* Let :math:`t` be the :ref:`value type <syntax-valtype>` :math:`\unpacktype(\storagetype)`.
+
+* The extension :math:`\sx` must be present of and only if :math:`t` is different from :math:`\storagetype`.


Suggested change

* The extension :math:`\sx` must be present of and only if :math:`t` is different from :math:`\storagetype`.

* The extension :math:`\sx` must be present if and only if :math:`t` is different from :math:`\storagetype`.

Fixed (and changed like above).

tlively · 2023-05-15T19:46:14Z

document/core/valid/instructions.rst

+:math:`\I31GET\K{\_}\sx`
+........................
+
+* The instruction is valid with type :math:`[(\REF~\I31)] \to [\I32]`.


Suggested change

* The instruction is valid with type :math:`[(\REF~\I31)] \to [\I32]`.

* The instruction is valid with type :math:`[(\REF~\NULL~\I31)] \to [\I32]`.

tlively · 2023-05-15T19:46:26Z

document/core/valid/instructions.rst

+.. math::
+   \frac{
+   }{
+     C \vdashinstr \I31GET\K{\_}\sx : [(\REF~\I31)] \to [\I32]


Suggested change

C \vdashinstr \I31GET\K{\_}\sx : [(\REF~\I31)] \to [\I32]

C \vdashinstr \I31GET\K{\_}\sx : [(\REF~\NULL~\I31)] \to [\I32]

document/core/valid/instructions.rst

Co-authored-by: Thomas Lively <tlively@google.com>

rossberg · 2023-05-23T19:23:02Z

@conrad-watt, ping.

rossberg · 2023-06-12T19:53:06Z

@conrad-watt, ping.

tlively · 2023-07-06T19:31:30Z

document/core/valid/instructions.rst

+
+.. math::
+   \frac{
+     \expand(C.\CTYPES[x]) = \TSTRUCT~(\MVAR~\X{st})


Suggested change

\expand(C.\CTYPES[x]) = \TSTRUCT~(\MVAR~\X{st})

\expand(C.\CTYPES[x]) = \TARRAY~(\MVAR~\X{st})

conrad-watt · 2023-07-05T06:50:17Z

document/core/syntax/types.rst

+Recursive Types
+~~~~~~~~~~~~~~~
+
+*Recursive types* denote a group of mutually recursive :ref:`structured types <syntax-strtype>`, each of which can optionally declare a list of supertypes that it :ref:`matches <match-strtype>`.


match-strtype here, and a few others elsewhere (references to syntax-type-dyn, syntax-type-aggregate, valid-rectype, match-deftype) give "label undefined" warnings when I try to build the PDF, although I guess these are coming in one of the follow-up PRs?

Yes, they come with #382.

conrad-watt · 2023-07-05T06:54:02Z

document/core/util/macros.def

@@ -255,6 +255,7 @@
 .. |structtype| mathdef:: \xref{syntax/types}{syntax-structtype}{\X{structtype}}


line 229 above (can't comment directly):
.. |TFINAL| mathdef:: \xref{syntax/types}{syntax-subtype}{\K{filan}}

should "filan" be "final"?

conrad-watt · 2023-07-05T07:08:17Z

document/core/syntax/types.rst

+.. note::
+   This definition computes an approximation of the reference type that is inhabited by all values from :math:`\X{rt}_1` except those from :math:`\X{rt}_2`.
+   Since the type system does not have general union types,
+   the defnition only affects the presence of null and cannot express the absence of other values.


typo: "defnition"

conrad-watt · 2023-07-05T07:42:10Z

document/core/valid/modules.rst


 .. math::
   \frac{
-     C.\CTYPES[x] = \functype
+     C.\CTYPES[x] = \TFUNC~\functype


should there be an expand here, or is this covered by the todo below?

Ah, no, fixed.

conrad-watt · 2023-07-05T07:43:15Z

document/core/valid/types.rst

@@ -169,7 +169,7 @@ Block Types

 .. math::
   \frac{
-     C.\CTYPES[\typeidx] = [t_1^\ast] \toF [t_2^\ast]
+     C.\CTYPES[\typeidx] = \TFUNC~[t_1^\ast] \toF [t_2^\ast]


similarly, should there be an expand here?

conrad-watt · 2023-07-09T18:40:41Z

document/core/valid/instructions.rst

+
+* The :ref:`reference type <syntax-reftype>` :math:`\X{rt}` must be :ref:`valid <valid-reftype>`.
+
+* Then the instruction is valid with type :math:`[\X{rt}'] \to [\I32]` for any :ref:`valid <valid-reftype>` :ref:`reference type <syntax-reftype>` :math:`\X{rt}'` that :ref:`matches <match-reftype>` :math:`\X{rt}`.


I read \X{rt} \matchesreftype \X{rt}' as "rt matches rt'". Is it ok that the prose states this relationship in the "opposite" direction (similar below)?

No, that was a bug. Fixed here and for ref.cast.

conrad-watt · 2023-07-09T19:49:17Z

document/core/valid/instructions.rst

@@ -1491,6 +1924,84 @@ Control Instructions
   }


+.. _valid-br_on_cast:
+
+:math:`\BRONCAST~l~\X{rt}_1~\X{rt}_2`


Do all of the below match the decisions made (or pending) in #381?

This PR reflects what's currently in MVP.md. Updating it is a separate action item blocked on #381.

conrad-watt

lgtm

Validation of instructions (plus some infra and fixes)

74cadad

rossberg requested a review from conrad-watt May 14, 2023 17:16

rossberg mentioned this pull request May 14, 2023

Spec authoring tracking issue #376

Open

53 tasks

tlively reviewed May 15, 2023

View reviewed changes

Comments

f68e10c

tlively reviewed May 16, 2023

View reviewed changes

document/core/valid/instructions.rst Outdated Show resolved Hide resolved

Update document/core/valid/instructions.rst

51dd778

Co-authored-by: Thomas Lively <tlively@google.com>

rossberg changed the base branch from spec.exec to main May 17, 2023 11:50

rossberg mentioned this pull request May 30, 2023

Spec type and module validation, subtyping, and module instantiation. #382

Merged

rossberg added 2 commits May 30, 2023 16:47

Merge branch 'main' into spec.valid-instr

6d681ea

Fix some errors

6f6ff28

rossberg mentioned this pull request Jul 4, 2023

Prose for basic struct/array instructions #393

Merged

tlively reviewed Jul 6, 2023

View reviewed changes

conrad-watt reviewed Jul 9, 2023

View reviewed changes

Comments

dd2cf49

conrad-watt approved these changes Jul 12, 2023

View reviewed changes

Merge branch 'main' into spec.valid-instr

16e6620

rossberg merged commit 76e0d6b into main Jul 12, 2023
4 checks passed

rossberg deleted the spec.valid-instr branch July 12, 2023 18:34

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Validation of instructions (plus some infra and fixes) #377

Validation of instructions (plus some infra and fixes) #377

rossberg commented May 14, 2023 •

edited

Loading

tlively May 15, 2023

rossberg May 16, 2023

tlively May 16, 2023

tlively May 15, 2023

rossberg May 16, 2023

tlively May 15, 2023

rossberg May 16, 2023

tlively May 15, 2023

rossberg May 16, 2023

tlively May 15, 2023

rossberg May 16, 2023

tlively May 15, 2023

rossberg May 16, 2023

tlively May 15, 2023

rossberg May 16, 2023

rossberg commented May 23, 2023

rossberg commented Jun 12, 2023

tlively Jul 6, 2023

rossberg Jul 11, 2023

conrad-watt Jul 5, 2023

rossberg Jul 11, 2023

conrad-watt Jul 5, 2023

rossberg Jul 11, 2023

conrad-watt Jul 5, 2023

rossberg Jul 11, 2023

conrad-watt Jul 5, 2023

rossberg Jul 11, 2023

conrad-watt Jul 5, 2023

rossberg Jul 11, 2023

conrad-watt Jul 9, 2023

rossberg Jul 11, 2023

conrad-watt Jul 9, 2023

rossberg Jul 11, 2023

conrad-watt left a comment

		Note: Cast instructions do _not_ require the operand's source type to be a supertype of the target type. It can also be a "sibling" in the same hierarchy, i.e., they only need to have a common supertype (in practice, it is sufficient to test that both types share the same top heap type.). Allowing so is necessary to maintain subtype substitutability, i.e., the ability to maintain well-typedness when operands are replaced by subtypes.


		* The :ref:`reference type <syntax-reftype>` :math:`\X{rt}` must be :ref:`valid <valid-reftype>`.

		* Then the instruction is valid with type :math:`[\X{rt}'] \to [\I32]` for any :ref:`valid <valid-reftype>` :ref:`reference type <syntax-reftype>` that :ref:`matches <match-reftype>` :math:`\X{rt}`.

		* Let :math:`t^\ast` be the concatenation of all :math:`t_i`.

		* Then the instruction is valid with type :math:`[t^\ast] \to [(\REF~x)]`.


		* Let :math:`t` be the :ref:`value type <syntax-valtype>` :math:`\unpacktype(\storagetype)`.

		* The extension :math:`\sx` must be present of and only if :math:`t` is different from :math:`\storagetype`.

	* The instruction is valid with type :math:`[(\REF~\I31)] \to [\I32]`.
	* The instruction is valid with type :math:`[(\REF~\NULL~\I31)] \to [\I32]`.

	C \vdashinstr \I31GET\K{\_}\sx : [(\REF~\I31)] \to [\I32]
	C \vdashinstr \I31GET\K{\_}\sx : [(\REF~\NULL~\I31)] \to [\I32]

	\expand(C.\CTYPES[x]) = \TSTRUCT~(\MVAR~\X{st})
	\expand(C.\CTYPES[x]) = \TARRAY~(\MVAR~\X{st})

		@@ -255,6 +255,7 @@
		.. \|structtype\| mathdef:: \xref{syntax/types}{syntax-structtype}{\X{structtype}}

Validation of instructions (plus some infra and fixes) #377

Validation of instructions (plus some infra and fixes) #377

Conversation

rossberg commented May 14, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rossberg commented May 23, 2023

rossberg commented Jun 12, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

conrad-watt left a comment

Choose a reason for hiding this comment

rossberg commented May 14, 2023 •

edited

Loading