View Revisions: Issue #36882

Summary 0036882: [Feature] Class and record definition XML dump extension
Revision 2020-04-07 05:55 by J. Gareth Moreton
Additional Information - "node-dump-extension-refactor.patch" should not change the current node dump behaviour, but moves some functions so non-node classes can use them.
- "node-dump-extension-defs.patch" requires "node-dump-extension-refactor.patch" to work, and contains the changes required to allow record and class definitions to be dumped to the relevant XML file.

For example, the declaration:

type TVec = record
  X, Y, Z: Single;
end;

Appears as the following in the XML dump:

   <definition name="TVec" pos="29,9">
      <type><record></type>
      <size>12</size>
      <alignment>4</alignment>
      <field name="X" pos="30,5">
         <type>Single</type>
         <visibility>vis_public</visibility>
         <offset>0</offset>
         <size>4</size>
      </field>
      <field name="Y" pos="30,8">
         <type>Single</type>
         <visibility>vis_public</visibility>
         <offset>4</offset>
         <size>4</size>
      </field>
      <field name="Z" pos="30,11">
         <type>Single</type>
         <visibility>vis_public</visibility>
         <offset>8</offset>
         <size>4</size>
      </field>
   </definition>

(I might have the visibility field be omitted later on if it is vis_public)

The idea behind this extra information in the node dump files, even though they're not actually nodes, is to aid with compiler development where vectorisation is concerned by confirming, say, the offsets and sizes of fields are suitable for transferring en masse to an XMM register, and studying a selection of nodes in the same file that might be suitable for vectorisation.
Revision 2020-04-07 05:54 by J. Gareth Moreton
Additional Information - "node-dump-extension-refactor.patch" should not change the current node dump behaviour, but moves some functions so non-node classes can use them.
- "node-dump-extension-defs.patch" requires "node-dump-extension-refactor.patch" to work, and contains the changes required to allow record and class definitions to be dumped to the relevant XML file.

For example, the declaration:

type TVec = record
  X, Y, Z: Single;
end;

Appears as the following in the XML dump:

   <definition name="TVec" pos="29,9">
      <type>&lt;record&gt;</type>
      <size>12</size>
      <alignment>4</alignment>
      <field name="X" pos="30,5">
         <type>Single</type>
         <visibility>vis_public</visibility>
         <offset>0</offset>
         <size>4</size>
      </field>
      <field name="Y" pos="30,8">
         <type>Single</type>
         <visibility>vis_public</visibility>
         <offset>4</offset>
         <size>4</size>
      </field>
      <field name="Z" pos="30,11">
         <type>Single</type>
         <visibility>vis_public</visibility>
         <offset>8</offset>
         <size>4</size>
      </field>
   </definition>

(I might have the visibility field be omitted later on if it is vis_public)

The idea behind this extra information in the node dump files, even though they're not actually nodes, is to aid with compiler development where vectorisation is concerned by confirming, say, the offsets and sizes of fields are suitable for transferring en masse to an XMM register, and studying a selection of nodes in the same file that might be suitable for vectorisation.
Revision 2020-04-07 05:53 by J. Gareth Moreton
Additional Information - "node-dump-extension-refactor.patch" should not change the current node dump behaviour, but moves some functions so non-node classes can use them.
- "node-dump-extension-defs.patch" requires "node-dump-extension-refactor.patch" to work, and contains the changes required to allow record and class definitions to be dumped to the relevant XML file.

For example, the declaration:

type TVec = record
  X, Y, Z: Single;
end;

Appears as the following in the XML dump:

   <definition name="TVec" pos="29,9">
      <type><record></type>
      <size>12</size>
      <alignment>4</alignment>
      <field name="X" pos="30,5">
         <type>Single</type>
         <visibility>vis_public</visibility>
         <offset>0</offset>
         <size>4</size>
      </field>
      <field name="Y" pos="30,8">
         <type>Single</type>
         <visibility>vis_public</visibility>
         <offset>4</offset>
         <size>4</size>
      </field>
      <field name="Z" pos="30,11">
         <type>Single</type>
         <visibility>vis_public</visibility>
         <offset>8</offset>
         <size>4</size>
      </field>
   </definition>

(I might have the visibility field be omitted later on if it is vis_public)

The idea behind this extra information in the node dump files, even though they're not actually nodes, is to aid with compiler development where vectorisation is concerned by confirming, say, the offsets and sizes of fields are suitable for transferring en masse to an XMM register, and studying a selection of nodes in the same file that might be suitable for vectorisation.
Revision 2020-04-07 05:52 by J. Gareth Moreton
Additional Information - "node-dump-extension-refactor.patch" should not change the current node dump behaviour, but moves some functions so non-node classes can use them.
- "node-dump-extension-defs.patch" requires "node-dump-extension-refactor.patch" to work, and contains the changes required to allow record and class definitions to be dumped to the relevant XML file.

For example, the declaration:

type TVec = record
  X, Y, Z: Single;
end;

Appears as the following in the XML dump:

   <definition name="TVec" pos="29,9">
      <type><record></type>
      <size>12</size>
      <alignment>4</alignment>
      <field name="X" pos="30,5">
         <type>Single</type>
         <visibility>vis_public</visibility>
         <offset>0</offset>
         <size>4</size>
      </field>
      <field name="Y" pos="30,8">
         <type>Single</type>
         <visibility>vis_public</visibility>
         <offset>4</offset>
         <size>4</size>
      </field>
      <field name="Z" pos="30,11">
         <type>Single</type>
         <visibility>vis_public</visibility>
         <offset>8</offset>
         <size>4</size>
      </field>
   </definition>

(I might have the visibility field be omitted later on if it is vis_public)

The idea behind this extra information in the node dump files, even though they're not actually nodes, is to aid with compiler development where vectorisation is concerned by confirming, say, the offsets and sizes of fields are suitable for transferring en masse to an XMM register, and studying a selection of nodes in the same file that might be suitable for vectorisation.
Revision 2020-04-07 05:50 by J. Gareth Moreton
Additional Information - "node-dump-extension-refactor.patch" should not change the current node dump behaviour, but moves some functions so non-node classes can use them.
- "node-dump-extension-defs.patch" requires "node-dump-extension-refactor.patch" to work, and contains the changes required to allow record and class definitions to be dumped to the relevant XML file.

For example, the declaration:

type TVec = record
  X, Y, Z: Single;
end;

Appears as the following in the XML dump:

   <definition name="Vec" pos="29,9">
      <type><record></type>
      <size>12</size>
      <alignment>4</alignment>
      <field name="X" pos="30,5">
         <type>Single</type>
         <visibility>vis_public</visibility>
         <offset>0</offset>
         <size>4</size>
      </field>
      <field name="Y" pos="30,8">
         <type>Single</type>
         <visibility>vis_public</visibility>
         <offset>4</offset>
         <size>4</size>
      </field>
      <field name="Z" pos="30,11">
         <type>Single</type>
         <visibility>vis_public</visibility>
         <offset>8</offset>
         <size>4</size>
      </field>
   </definition>

(I might have the visibility field be omitted later on if it is vis_public)

The idea behind this extra information in the node dump files, even though they're not actually nodes, is to aid with compiler development where vectorisation is concerned by confirming, say, the offsets and sizes of fields are suitable for transferring en masse to an XMM register, and studying a selection of nodes in the same file that might be suitable for vectorisation.