This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2 1/3] Add AVX512 registers support to GDB.
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: michael dot sturm at intel dot com
- Cc: palves at redhat dot com, eliz at gnu dot org, gdb-patches at sourceware dot org, michael dot sturm at intel dot com, walfred dot tedeschi at intel dot com
- Date: Thu, 27 Feb 2014 20:11:02 +0100 (CET)
- Subject: Re: [PATCH v2 1/3] Add AVX512 registers support to GDB.
- Authentication-results: sourceware.org; auth=none
- References: <1392907965-32637-1-git-send-email-michael dot sturm at intel dot com> <1392907965-32637-2-git-send-email-michael dot sturm at intel dot com> <201402232252 dot s1NMql7R012111 at glazunov dot sibelius dot xs4all dot nl> <530CAD5C dot 20900 at intel dot com>
> Date: Tue, 25 Feb 2014 15:49:00 +0100
> From: "Sturm, Michael" <michael.sturm@intel.com>
>
> Hi Mark,
>
> thanks a lot for the review. Please see comments below.
>
> Regards,
> Michael & Fred
>
> > Hi Michael,
> >
> > Finally found some time to review this diff. Sorry for the delay.
> >
> > Any particular reason why you didn't make %zmm16-%zmm31 the real "raw"
> > registers and %ymm16-%ymm31 and %xmm16-%ymm31 pseudo-register views
> > into those? Seems more logical as they are provided as contigious
> > 512-bit areas in the xsave storage area. I think that would actually
> > simply the code, but I may be wrong. It certainly would simply the
> > on-the-wire formats for remote debugging as specified in the xml files.
> Interesting question! Actually, we've started implementation following
> this approach.
> But when we did first internal reviews of the patch, we found that the
> symmetry with existing code
> for XMM and YMM registers would be broken and code would be duplicated
> in some points and more complex and asymmetrical in others:
>
> - the type definitions for xmm16-31 and ymm16-31 pseudo registers in the
> XML files would
> need to be repeated in the code.
> - the implementation of xmm16-31 and ymm16-31 would be different from
> the implementation of
> xmm0-15 and ymm0-15
> - there would be different code for zmm0-15 and zmm16-31.
>
> So we opted for simpler and more symmetric code.
Fair enough. Consider an updated diff with the coding style issues I
pointed out pre-approved. Thanks for your patience.