rmail/gcc-patches/2020-June/547463.html
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> Jakub
> > Jelinek via Gcc-patches
> > Sent: Monday, June 8, 2020 2:57 PM
> > To: Tobias Burnus
> > Cc: Uros Bizjak ; gcc-patches@gcc.gnu.org
> >
On Mon, Jun 08, 2020 at 03:49:17PM +0200, Tobias Burnus wrote:
> Hi,
>
> I just observe that this patch causes our *nonbootstrap* builds
> to fail; I have not yet looked into this nor tried a bootstrap
> build.
>
> gcc-mainline/gcc/expr.c: In function 'rtx_insn* emit_move_insn(rtx, rtx)':
> gcc-m
chard Sandiford [mailto:richard.sandif...@arm.com]
Sent: Monday, June 1, 2020 4:47 PM
To: Yangfei (Felix)
Cc: gcc-patches@gcc.gnu.org; Uros Bizjak ; Jakub
Jelinek ; Hongtao Liu ; H.J. Lu
Subject: Re: [PATCH PR95254] aarch64: gcc generate inefficient code
with
fixed sve vector length
Snip...
6/2/20 4:44 AM, Yangfei (Felix) wrote:
Hi,
-Original Message-
From: Richard Sandiford [mailto:richard.sandif...@arm.com]
Sent: Monday, June 1, 2020 4:47 PM
To: Yangfei (Felix)
Cc: gcc-patches@gcc.gnu.org; Uros Bizjak ; Jakub
Jelinek ; Hongtao Liu ; H.J. Lu
Subject: Re: [PATCH PR95254] aarch64:
Cc: gcc-patches@gcc.gnu.org; Uros Bizjak ; Jakub
>>> Jelinek ; Hongtao Liu ; H.J. Lu
>>>
>>> Subject: Re: [PATCH PR95254] aarch64: gcc generate inefficient code with
>>> fixed sve vector length
>>
>> Snip...
>>
>>> Sounds good. May
4] aarch64: gcc generate inefficient code with
> fixed sve vector length
>
Snip...
> >
> >> FAIL: gcc.target/i386/avx512f-vcvtps2ph-2.c (test for excess errors)
> >> UNRESOLVED: gcc.target/i386/avx512f-vcvtps2ph-2.c compilation failed
> >> to produce executab
; Jelinek ; Hongtao Liu ; H.J. Lu
>>
>> Subject: Re: [PATCH PR95254] aarch64: gcc generate inefficient code with
>> fixed sve vector length
>
> Snip...
>
>> Sounds good. Maybe at this point the x_inner and y_inner code is getting
>> complicated enough
4] aarch64: gcc generate inefficient code with
> fixed sve vector length
Snip...
> Sounds good. Maybe at this point the x_inner and y_inner code is getting
> complicated enough to put into a lambda too:
>
> x_inner = ... (x);
> y_inner = ... (y);
>
> Just a suggestio
; Jelinek ; Hongtao Liu ; H.J. Lu
>>
>> Subject: Re: [PATCH PR95254] aarch64: gcc generate inefficient code with
>> fixed sve vector length
>>
>
> Snip...
>
>> >
>> > The v5 patch attached addressed this issue.
>> >
>> > Th
4] aarch64: gcc generate inefficient code with
> fixed sve vector length
>
Snip...
> >
> > The v5 patch attached addressed this issue.
> >
> > There two added changes compared with the v4 patch:
> > 1. In candidate_mem_p, mov_optab for innermode should be availab
"Yangfei (Felix)" writes:
> Turns out that this ICE triggers under x86 -m32.
>
> Command to reproduce:
> ~/build-gcc/x86_64-pc-linux-gnu/32/libgcc$ gcc -g -O2 -m32 -O2 -g -O2
> -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
> -Wstrict-prototypes -Wmissing-prototypes -Wold-styl
Hi,
> -Original Message-
> From: Yangfei (Felix)
> Sent: Friday, May 29, 2020 2:56 PM
> To: 'Hongtao Liu' ; H.J. Lu
> Cc: gcc-patches@gcc.gnu.org; Uros Bizjak ; Jakub
> Jelinek ; Richard Sandiford
>
> Subject: RE: [PATCH PR95254] aarch64: gcc generate
4] aarch64: gcc generate inefficient code with
> fixed sve vector length
>
Snip...
> > >
> > > This is due to define_subst magic. The generators automatically
> > > create a vec_merge form of the instruction based on the information
> > > in the attributes
On Thu, May 28, 2020 at 11:37 PM H.J. Lu wrote:
>
> On Thu, May 28, 2020 at 8:00 AM Richard Sandiford
> wrote:
> >
> > "Yangfei (Felix)" writes:
> > > Thanks for reviewing this.
> > > Attached please find the v5 patch.
> > > Note: we also need to modify local variable "mode" once we catch one
>
On Thu, May 28, 2020 at 8:00 AM Richard Sandiford
wrote:
>
> "Yangfei (Felix)" writes:
> > Thanks for reviewing this.
> > Attached please find the v5 patch.
> > Note: we also need to modify local variable "mode" once we catch one case.
> > I see test failure without this change.
>
> Looks good.
"Yangfei (Felix)" writes:
> Thanks for reviewing this.
> Attached please find the v5 patch.
> Note: we also need to modify local variable "mode" once we catch one case. I
> see test failure without this change.
Looks good. Patch is OK assuming the x86 folks don't want to rewrite
gcc.target/i38
Hi,
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Thursday, May 28, 2020 12:07 AM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR95254] aarch64: gcc generate inefficient code with
> fixed sve v
"Yangfei (Felix)" writes:
>> > +
>> > +{
>> > + x = x_inner;
>> > +}
>> > + else if (x_inner != NULL_RTX && MEM_P (y)
>> > + && known_eq (GET_MODE_SIZE (x_inner_mode),
>> GET_MODE_SIZE (mode))
>> > + && ! targetm.can_change_mode_class (x_inner_mode, mode,
>> ALL_REGS)
>> > +
Hi,
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Tuesday, May 26, 2020 11:58 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR95254] aarch64: gcc generate inefficient code with
> fixed sve vec
Sorry for the slow reply, was off for a few days.
I think the new code ought to happen earlier in emit_move_insn, before:
if (CONSTANT_P (y))
{
That way, all the canonicalisation happens on the mode we actually
want the move to have.
"Yangfei (Felix)" writes:
> diff --git a/gcc/expr.c b/
Hi Richard,
Thanks for the suggestions.
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Thursday, May 21, 2020 5:22 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR95254] aarch64: gcc generat
"Yangfei (Felix)" writes:
> Hi,
>
> Notice a tiny SVE-related performance issue:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95254
>
> For the given test case, SLP succeeds with VNx8HImode with or without
> option -msve-vector-bits=256.
> The root cause for the difference is that we c
Hi,
Notice a tiny SVE-related performance issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95254
For the given test case, SLP succeeds with VNx8HImode with or without option
-msve-vector-bits=256.
The root cause for the difference is that we choose a different mode in
aarch64_vector
23 matches
Mail list logo