This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: (R5900) Implementing Vector Support
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Woon yung Liu <ysai187 at yahoo dot com>, Richard Henderson <rth at redhat dot com>, "Gcc Mailing List" <gcc at gcc dot gnu dot org>
- Date: Fri, 3 Jun 2016 13:36:42 +0000
- 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>
Woon yung Liu <ysai187@yahoo.com> writes:
> On Wednesday, June 1, 2016 5:45 AM, Richard Henderson <rth@redhat.com>
> wrote:
> > This is almost always incorrect, and certainly before reload.
> > You need to use gen_lowpart. There are examples in the code
>
> > fragments that I sent the other week.
>
> The problem is that gen_lowpart() doesn't seem to support casting to
> other modes of the same size.
> When I use it, the assert within gen_lowpart_general() will fail due to
> gen_lowpart_common() rejecting the operation (new mode size is not
> smaller than the old).
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.
> > You need to read the gcc internals documentation. They are all three
> different
>
> > uses, though there is some overlap between define_insn and
> define_expand.
>
> I actually read the GCC internals documentation before I even begun any
> attempt at this, but there was still a lot that I did not successfully
> grasp.
>
> I'll go with define_expand then.
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.
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.
> But I am already doubting that I will complete this port as I can no
> longer see a favourable conclusion.
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,
Matthew