<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 28, 2023 at 1:17 PM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> DW_AT[_GNU]_vector is best understood not as "a hardware vector register" but rather as a marker that "this type is eligible to be passed in hardware vector registers at function boundaries according to the platform ABI".<br>
<br>
My 2c would not be to describe these in terms of<br>
hardware/implementations (that gets confusing/blurs the line between<br>
variable/types and locations - as you say, these things can be stored<br>
in memory, so they aren't uniquely in registers - you might have a<br>
member of this type in a struct passed in memory and need to know the<br>
ABI/struct layout for that, etc), but at the source level - which the<br>
ABI is defined in those same terms. Overloading, for instance, still<br>
applies if these are different types - so other debugger features need<br>
to work based on this type information.<br>
<br>
So it seems like a simpler question is:<br>
<br>
How should DWARF producers/consumers expect to encode the source<br>
example Ben provided (well, simplified a bit):<br>
<br>
#include <x86intrin.h><br>
<br>
void f( __m128 a){<br>
}<br>
<br>
What DWARF should be used to describe the type of 'a'? And how does<br>
this encoding scale to all the other similar intrinsic types?<br></blockquote><div><br></div><div>Stepping back even further I'd ask what information does the compiler need to communicate to the debugger or other tools that's not communicated by the DWARF for e.g. double[4]? The only information I'm personally aware of is the ABI stuff I mentioned before, but there may very well be other things lurking.<br></div><div><br></div><div>- Kyle<br></div></div></div>