<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 3/27/23 23:51, Cary Coutant wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJimCsFzSAL_VNWN=Q4qEOCrHjpOMxwPXBuaE3KV87+3Xe_KkA@mail.gmail.com">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Vector registers
It has been the long standing existing practice to treat hardware
vector registers as arrays of a fundamental base type. To deliniate
these hardware register arrays from arrays in the language source they
have been given the DW_AT_GNU_vector attribute. This proposal simply
standardizes the existing behavior.
In Section 2.2 Attribute Types, DW_AT_vector and
DW_AT_variable_vector_width shall be added to Table 2.2
--------------------------------------------------------------------
DW_AT_vector | A hardware vector register
DW_AT_variable_vector_width | Array bound for hardware
| implementation defined vector register
| width
--------------------------------------------------------------------
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I don't understand what tags this DW_AT_vector attribute would apply
to. Vector registers aren't *types*, they're *locations*, so it
doesn't really make sense to me to put this attribute on a
DW_TAG_array_type. </pre>
</blockquote>
<p>Maybe I should have said. <br>
</p>
<pre class="moz-quote-pre" wrap=""> DW_AT_vector | A hardware vector register type</pre>
<p>because what I'm talking about are types not locations. Consider
a simple program like:</p>
#include <x86intrin.h><br>
<br>
__m128 *f( __m128 a, float *b){<br>
__m128 *c=new __m128;<br>
*c=_mm_load_ps(b);<br>
*c+=a;<br>
return c;<br>
}<br>
<p>Which when compiled by GCC generates DWARF like this:</p>
<p> [ 7c] base_type abbrev: 3<br>
byte_size (data1) 4<br>
encoding (data1) float (4)<br>
name (strp) "float"<br>
<snip><br>
[ 7c5] typedef abbrev: 8<br>
name (strp) "__m128"<br>
decl_file (data1) xmmintrin.h (2)<br>
decl_line (data1) 69<br>
decl_column (data1) 15<br>
type (ref4) [ 7d1]<br>
[ 7d1] array_type abbrev: 30<br>
GNU_vector (flag_present) yes<br>
type (ref4) [ 7c]<br>
sibling (ref4) [ 7dd]<br>
[ 7da] subrange_type abbrev: 31<br>
upper_bound (data1) 3<br>
[ 7dd] base_type abbrev: 3<br>
byte_size (data1) 2<br>
encoding (data1) float (4)<br>
name (strp) "_Float16"<br>
[ 7e4] subprogram abbrev: 32<br>
external (flag_present) yes<br>
name (string) "f"<br>
decl_file (data1) vecreg.C (1)<br>
decl_line (data1) 3<br>
decl_column (data1) 9<br>
linkage_name (strp) "_Z1fDv4_fPf"<br>
type (ref4) [ 881]<br>
low_pc (addr) .text+000000000000000000
<_Z1fDv4_fPf><br>
high_pc (data8) 38
(.bss+000000000000000000)<br>
frame_base (exprloc) <br>
[ 0] call_frame_cfa<br>
call_all_calls (flag_present) yes<br>
sibling (ref4) [ 881]<br>
[ 808] formal_parameter abbrev: 15<br>
name (string) "a"<br>
decl_file (implicit_const) vecreg.C (1)<br>
decl_line (implicit_const) 3<br>
decl_column (data1) 19<br>
type (ref4) [ 7c5]<br>
location (sec_offset) location list
[ 10]<br>
GNU_locviews (sec_offset) location list
[ c]<br>
[ 818] formal_parameter abbrev: 15<br>
name (string) "b"<br>
decl_file (implicit_const) vecreg.C (1)<br>
decl_line (implicit_const) 3<br>
decl_column (data1) 29<br>
type (ref4) [ 886]<br>
location (sec_offset) location list
[ 22]<br>
GNU_locviews (sec_offset) location list
[ 1c]<br>
[ 828] variable abbrev: 33<br>
name (string) "c"<br>
decl_file (data1) vecreg.C (1)<br>
decl_line (data1) 4<br>
decl_column (data1) 11<br>
type (ref4) [ 881]<br>
location (sec_offset) location list
[ 37]<br>
GNU_locviews (sec_offset) location list
[ 35]<br>
<snip><br>
[ 881] pointer_type abbrev: 5<br>
byte_size (implicit_const) 8<br>
type (ref4) [ 7c5]<br>
[ 886] pointer_type abbrev: 5<br>
byte_size (implicit_const) 8<br>
type (ref4) [ 7c]<br>
</p>
<p>----------------</p>
<p> Offset: 10, Index: 4<br>
offset_pair 0, 15<br>
.text+000000000000000000 <_Z1fDv4_fPf>..<br>
.text+0x0000000000000014 <_Z1fDv4_fPf+0x14><br>
[ 0] reg17<br>
offset_pair 15, 26<br>
.text+0x0000000000000015 <_Z1fDv4_fPf+0x15>..<br>
.text+0x0000000000000025 <_Z1fDv4_fPf+0x25><br>
[ 0] fbreg -32<br>
end_of_list<br>
<br>
Offset: 1c, Index: 10<br>
view pair 0, 0<br>
view pair 0, 0<br>
view pair 0, 0<br>
<br>
Offset: 22, Index: 16<br>
offset_pair 0, 9<br>
.text+000000000000000000 <_Z1fDv4_fPf>..<br>
.text+0x0000000000000008 <_Z1fDv4_fPf+0x8><br>
[ 0] reg5<br>
offset_pair 9, 25<br>
.text+0x0000000000000009 <_Z1fDv4_fPf+0x9>..<br>
.text+0x0000000000000024 <_Z1fDv4_fPf+0x24><br>
[ 0] reg3<br>
offset_pair 25, 26<br>
.text+0x0000000000000025 <_Z1fDv4_fPf+0x25>..<br>
.text+0x0000000000000025 <_Z1fDv4_fPf+0x25><br>
[ 0] entry_value:<br>
[ 0] reg5<br>
[ 3] stack_value<br>
end_of_list<br>
<br>
</p>
<p>The things that I wanted to point out with this example are: <br>
</p>
<ul>
<li>that a vector is a type, in this case __mm128</li>
<li>As a location it is different than a packed array with the
same type that it contains. <br>
</li>
<li>This vector type can have a location that exists in memory,
but also can exist in a register. In this case it exists both in
reg17 and on fbreg-32 (on the stack)<br>
</li>
</ul>
Also it should be noted that clang (thankfully) copies gcc's
behavior in this respect at least on linux. For example:
<p>DWARF section [ 6] '.debug_info' at offset 0x27b:<br>
[Offset]<br>
Compilation unit at offset 0:<br>
Version: 4, Abbreviation section offset: 0, Address size: 8,
Offset size: 4<br>
[ b] compile_unit abbrev: 1<br>
producer (strp) "clang version 15.0.7
(Fedora 15.0.7-2.fc37)"<br>
language (data2) C_plus_plus_14 (33)<br>
name (strp) "vecreg.C"<br>
stmt_list (sec_offset) 0<br>
comp_dir (strp) "/home/ben/Shared/test"<br>
low_pc (addr) .text+000000000000000000
<_Z1fDv4_fPf><br>
high_pc (data4) 38
(.text+0x0000000000000026)<br>
[ 2a] pointer_type abbrev: 2<br>
type (ref4) [ 2f]<br>
[ 2f] const_type abbrev: 3<br>
type (ref4) [ 34]<br>
[ 34] typedef abbrev: 4<br>
type (ref4) [ 3f]<br>
name (strp) "__m128"<br>
decl_file (data1) xmmintrin.h (1)<br>
decl_line (data1) 21<br>
[ 3f] array_type abbrev: 5<br>
GNU_vector (flag_present) yes<br>
type (ref4) [ 4b]<br>
[ 44] subrange_type abbrev: 6<br>
type (ref4) [ 52]<br>
count (data1) 4<br>
[ 4b] base_type abbrev: 7<br>
name (strp) "float"<br>
encoding (data1) float (4)<br>
byte_size (data1) 4<br>
[ 52] base_type abbrev: 8<br>
name (strp) "__ARRAY_SIZE_TYPE__"<br>
byte_size (data1) 8<br>
encoding (data1) unsigned (7) <br>
</p>
<blockquote type="cite"
cite="mid:CAJimCsFzSAL_VNWN=Q4qEOCrHjpOMxwPXBuaE3KV87+3Xe_KkA@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">We don't have DW_TAGs that describe registers; the
ABI defines the registers and DWARF producers and consumers should
understand and agree on the sizes and shapes of the various registers.</pre>
</blockquote>
<p>Right and they do as you can see from the fragment above reg17 is
the vector register. <br>
</p>
<p>The one tricky complication is ARM SVE and RISC-V RVV where the
vector width is not an architectural feature but a particular
hardware implementation feature. To be able to know the actual
vector length you have to read a machine specific register that
tells you the length of the vector registers in that machine.
Never the less SVE types can be passed as parameters between
functions and the ABI for the architecture explains how. This
creates some interesting DWARF expressions.<br>
</p>
<blockquote type="cite"
cite="mid:CAJimCsFzSAL_VNWN=Q4qEOCrHjpOMxwPXBuaE3KV87+3Xe_KkA@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">
In Tony's proposal, the new attribute modifies a base type, thus
introducing a vector type, which might get placed in a vector
register. But there, I don't see how the vector base type is
fundamentally different from an array type. It seems it's just a dodge
to make it a base type so that we can put whole vectors on the stack.</pre>
</blockquote>
<p>From a type system point of view they are the same and therefore
I can see the appeal of just making them base types for a
particular architecture. The thing that I worry about is the
combinatorial expansion of the base types. <br>
</p>
<p>In code that is different than what posted above, the
indexability of the type is important making it behave more like
an array.
</p>
<blockquote type="cite"
cite="mid:CAJimCsFzSAL_VNWN=Q4qEOCrHjpOMxwPXBuaE3KV87+3Xe_KkA@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">Maybe what we're looking for is a DW_TAG_vector_type, whose DW_AT_type
attribute gives the base type for each element of the vector. This
seems to be more DWARF-like, and if we decide there's a reason to
allow stack entries with vector types, we can do that.</pre>
</blockquote>
In what ways would DW_TAG_vector_type be different than
DW_TAG_array?<br>
<p>-ben</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAJimCsFzSAL_VNWN=Q4qEOCrHjpOMxwPXBuaE3KV87+3Xe_KkA@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">
-cary
</pre>
</blockquote>
</body>
</html>