[Dwarf-discuss] ISSUE: CPU vector types.

Kyle Huey khuey@pernos.co
Wed Mar 29 01:10:33 GMT 2023

On Tue, Mar 28, 2023 at 1:17 PM David Blaikie <dblaikie@gmail.com> wrote:

> > 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".
> My 2c would not be to describe these in terms of
> hardware/implementations (that gets confusing/blurs the line between
> variable/types and locations - as you say, these things can be stored
> in memory, so they aren't uniquely in registers - you might have a
> member of this type in a struct passed in memory and need to know the
> ABI/struct layout for that, etc), but at the source level - which the
> ABI is defined in those same terms. Overloading, for instance, still
> applies if these are different types - so other debugger features need
> to work based on this type information.
> So it seems like a simpler question is:
> How should DWARF producers/consumers expect to encode the source
> example Ben provided (well, simplified a bit):
> #include <x86intrin.h>
> void f( __m128 a){
> }
> What DWARF should be used to describe the type of 'a'? And how does
> this encoding scale to all the other similar intrinsic types?

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.

- Kyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20230328/3ec7891f/attachment-0001.htm>

More information about the Dwarf-discuss mailing list