This is the mail archive of the
mailing list for the GCC project.
Re: (R5900) Implementing Vector Support
- From: Woon yung Liu <ysai187 at yahoo dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>, Richard Henderson <rth at redhat dot com>, Gcc Mailing List <gcc at gcc dot gnu dot org>
- Date: Sat, 4 Jun 2016 02:57:40 +0000 (UTC)
- Subject: Re: (R5900) Implementing Vector Support
- Authentication-results: sourceware.org; auth=none
- References: <23a57920-3e9e-05f9-e428-a7e5e89d4de9 at redhat dot com> <133091800 dot 362759 dot 1462978450117 dot JavaMail dot yahoo at mail dot yahoo dot com> <93d40024-8baf-f571-765e-3f3ae59961df at redhat dot com> <687383190 dot 1940916 dot 1463221310394 dot JavaMail dot yahoo at mail dot yahoo dot com> <850bcd56-a219-a153-b467-8414fa19c207 at redhat dot com> <300510214 dot 326837 dot 1463573792037 dot JavaMail dot yahoo at mail dot yahoo dot com> <e7ccb4e0-6b37-ea2c-01bb-4fff2742ca32 at redhat dot com> <1735082185 dot 4758122 dot 1463655944237 dot JavaMail dot yahoo at mail dot yahoo dot com> <1809107277 dot 905923 dot 1464508754638 dot JavaMail dot yahoo at mail dot yahoo dot com> <1ad4a4a6-72ee-3048-0b9d-53ed16c5a4c8 at redhat dot com> <904764586 dot 674015 dot 1464958440737 dot JavaMail dot yahoo at mail dot yahoo dot com> <6D39441BF12EF246A7ABCE6654B023537E43748E at HHMAIL01 dot hh dot imgtec dot org>
- Reply-to: Woon yung Liu <ysai187 at yahoo dot com>
On Friday, June 3, 2016 9:36 PM, Matthew Fortune <Matthew.Fortune@imgtec.com> wrote:
> The conclusion we came to when developing MSA is that simplify_gen_subreg
> is the way to go for converting between vector modes:
> simplify_gen_subreg (new_mode, rtx, old_mode, 0)
> I'm not sure there is much need to change modes after reload so do it
> upfront at expand time or when splitting and you should be OK.
> See trunk mips.c for a number of uses of this when converting vector modes.
Thank you. I will try to go with your suggestion after the segmentation fault is taken care of, given that the MSA stuff is newer and similar.
> define_expand only provides a way to generate an instruction or sequence
> of instructions to achieve the overall goal. You must also have
> define_insn definitions for any pattern you emit or the generated code
> will fail to match.
This description seems to fit exactly what I've been trying to do so far. All patterns emitted as part of the expands, do exist.
> A define_insn_and_split is just shorthand for a define_insn where one
> or more output patterns are '#' (split) and you want to define the
> split alongside the instruction rather than as a separate define_split.
> As far as I understand the difference is syntactic sugar.
Thank you for clearing this up.
> It may take time but I'm sure we can help talk through the problems. As
> a new GCC developer you are a welcome addition to the community.
Thanks and regards,