install if it's
good to go.
Felix
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Friday, July 31, 2020 5:33 PM
> To: Zhongyunde
> Cc: gcc-patches@gcc.gnu.org; Yangfei (Felix)
> Subject: Re: [PATCH PR95696] regrename creat
Hi,
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Thursday, July 2, 2020 5:17 PM
> To: Yangfei (Felix)
> Cc: Richard Biener ; Richard Biener
> ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR95961] vect: ICE: in exact_di
Hi,
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Wednesday, July 1, 2020 9:03 PM
> To: Yangfei (Felix)
> Cc: Richard Biener ; Richard Biener
> ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR95961] vect: ICE: in exact_di
Hi,
> -Original Message-
> From: Richard Biener [mailto:rguent...@suse.de]
> Sent: Tuesday, June 30, 2020 10:50 PM
> To: Richard Sandiford
> Cc: Richard Biener ; Yangfei (Felix)
> ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR95961] vect: ICE: in exact_div, at po
Hi,
PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95961
In the test case for PR95961, vectorization factor computed by
vect_determine_vectorization_factor is [8,8]. But this is updated to [1,1]
later by vect_update_vf_for_slp.
When we call vect_get_num_vectors in vect_enhance_data_refs
Hi,
Noticed two places in tree-vect-data-refs.c where we can use function
vect_relevant_for_alignment_p.
Looks like these two are missed when we were introducing the function.
Bootstrapped and tested on aarch64-linux-gnu. OK to go?
ChangeLog modification is contained in the patch.
Than
Hi,
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Monday, June 15, 2020 5:12 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] vect: Use LOOP_VINFO_DATAREFS and
> LOOP_VINFO_DDRS consistently
Hi Richard,
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Monday, June 15, 2020 3:25 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] vect: Use LOOP_VINFO_DATAREFS and
> LOOP_VINFO_DDRS consiste
Hi,
This is minor code refactorings in tree-vect-data-refs.c and tree-vect-loop.c.
Use LOOP_VINFO_DATAREFS and LOOP_VINFO_DDRS when possible and rename
several parameters to make code more consistent.
Bootstrapped and tested on aarch64-linux-gnu. OK?
Thanks,
Felix
gcc/
+2020-06-13 Felix Yang
Hi,
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Friday, June 12, 2020 2:29 AM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR95570] vect: ICE: Segmentation fault in
> vect_loop_versioning
Hi,
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Thursday, June 11, 2020 12:23 AM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR95570] vect: ICE: Segmentation fault in
> vect_loop_versioning
Hi,
PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95570
Here, we are doing loop versioning for alignment. The only dr here is a
gather-statter operation: x[start][i].
Scalar evolution analysis for this dr failed, so DR_STEP is NULL_TREE, which
leads to the segfault.
But scatter-gather
Hi,
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Tuesday, June 2, 2020 7:17 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org; Uros Bizjak ; Jakub
> Jelinek ; Hongtao Liu ; H.J. Lu
>
> Subject: Re: [PATCH PR9525
Hi Richard,
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Wednesday, June 3, 2020 1:19 AM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR95459] aarch64: ICE in aarch64_short_vector_p, at
> con
Hi,
Please review this trivial patch fixing an ICE in aarch64_short_vector_p.
Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95459
In aarch64_short_vector_p, we are simply checking whether a type (and a
mode)
is a 64/128-bit short vector or not. This should not be affected b
Gentle ping ...
> -Original Message-
> From: Yangfei (Felix)
> Sent: Wednesday, May 27, 2020 11:52 AM
> To: 'Segher Boessenkool'
> Cc: gcc-patches@gcc.gnu.org; Zhanghaijian (A)
> Subject: RE: [PATCH PR94026] combine missed opportunity to simplify
>
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 PR9525
Hi,
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Sunday, May 31, 2020 12:01 AM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org; Uros Bizjak ; Jakub
> Jelinek ; Hongtao Liu ; H.J. Lu
>
> Subject: Re: [PATCH PR9525
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
Hi,
> -Original Message-
> From: Hongtao Liu [mailto:crazy...@gmail.com]
> Sent: Friday, May 29, 2020 11:24 AM
> To: H.J. Lu
> Cc: Yangfei (Felix) ; gcc-patches@gcc.gnu.org;
> Uros Bizjak ; Jakub Jelinek ;
> Richard Sandiford
> Subject: Re: [PATCH PR9525
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
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
Hi,
> -Original Message-
> From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
> Sent: Tuesday, May 26, 2020 11:32 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org; Zhanghaijian (A)
> Subject: Re: [PATCH PR94026] combine missed opportunity to simplify
Hi,
> -Original Message-
> From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
> Sent: Tuesday, May 26, 2020 12:27 AM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org; Zhanghaijian (A)
> Subject: Re: [PATCH PR94026] combine missed opportunity to simplify
Hi,
> -Original Message-
> From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
> Sent: Saturday, May 23, 2020 10:57 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org; Zhanghaijian (A)
> Subject: Re: [PATCH PR94026] combine missed opportunity to simplify
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
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
Hi,
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Monday, May 11, 2020 10:27 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR94991] aarch64: ICE: Segmentation fault with option -
> mgenera
Hi,
Witnessed another ICE with option -mgeneral-regs-only.
I have created a bug for that:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94991
For the given testcase, we are doing FAIL for scalar floating move expand
pattern since TARGET_FLOAT
is false with option -mgeneral-regs-only. B
Hi,
> -Original Message-
> From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
> Sent: Tuesday, March 24, 2020 10:58 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org; Zhanghaijian (A)
> Subject: Re: [PATCH PR94026] combine missed opportunity to simplify
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Monday, April 27, 2020 6:10 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR94784] ICE: in simplify_vector_constructor, at tree-
> ssa-forwpr
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Monday, April 27, 2020 3:51 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR94784] ICE: in simplify_vector_constructor, at tree-
> ssa-forwprop
Hi,
I see one gcc_assert was introduce in:
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544271.html
This is causing an ICE for certain cases. I have created a PR for this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94784
I did some check and it looks like everything works fine
Hi,
I noticed that gcc.target/aarch64/pragma_cpp_predefs_1.c performs testing
for -mgeneral-regs-only.
This adds similar testing in the following two tests to make sure CPP
predefines redefinitions on #pragma
works as expected when -mgeneral-regs-only option is specified (See
PR9467
Hi,
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Wednesday, April 22, 2020 6:03 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR94678] aarch64: unexpected result with -mgeneral-
> regs-onl
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Tuesday, April 21, 2020 6:11 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR94678] aarch64: unexpected result with -mgeneral-
> regs-on
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Tuesday, April 21, 2020 4:01 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR94678] aarch64: unexpected result with -mgeneral-
> regs-only and sve
Hi,
It looks like there are several issues out there for sve codegen with
-mgeneral-regs-only.
I have created a bug for that:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94678
We do ISA extension checks for SVE in
check_required_extensions(aarch64-sve-builtins.cc).
I think we may a
Hi!
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Tuesday, March 31, 2020 4:55 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org; rguent...@suse.de
> Subject: Re: [PATCH] ICE: in vectorizable_load, at tree-vect-stmts.c:9
Hi!
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Monday, March 30, 2020 8:08 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org; rguent...@suse.de
> Subject: Re: [PATCH] ICE: in vectorizable_load, at tree-vect-stmts.c:
Hi!
> -Original Message-
> From: Yangfei (Felix)
> Sent: Monday, March 30, 2020 5:28 PM
> To: gcc-patches@gcc.gnu.org
> Cc: 'rguent...@suse.de'
> Subject: [PATCH] ICE: in vectorizable_load, at tree-vect-stmts.c:9173
>
> Hi,
>
> New bug: https://gc
Hi,
New bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94398
With -mstrict-align, aarch64_builtin_support_vector_misalignment will returns
false when misalignment factor is unknown at compile time.
Then vect_supportable_dr_alignment returns dr_unaligned_unsupported, which
triggers the ICE.
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Thursday, March 26, 2020 3:37 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [RFC] Should widening_mul should consider block frequency?
>
> >
>
Hi!
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, March 24, 2020 10:14 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [RFC] Should widening_mul should consider block frequency?
>
> >
Hi!
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Monday, March 23, 2020 11:25 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [RFC] Should widening_mul should consider block frequency?
>
> On Mon,
Hi!
> -Original Message-
> From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
> Sent: Monday, March 23, 2020 8:10 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org; Zhanghaijian (A)
> Subject: Re: [PATCH PR94026] combine missed opportunity to simplify
Hi,
I created a bug for this issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94269
Looks like widening_mul phase may move multiply instruction from outside the
loop to inside the loop, merging with one add instruction inside the loop.
This will increase the cost of the loop at least
> -Original Message-
> From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
> Sent: Friday, March 20, 2020 9:38 AM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org; Zhanghaijian (A)
> Subject: Re: [PATCH PR94026] combine missed opportunity to simplify
>
Hi,
> -Original Message-
> From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
> Sent: Thursday, March 19, 2020 7:52 AM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org; Zhanghaijian (A)
> Subject: Re: [PATCH PR94026] combine missed opportunity to simplify
Hi,
> -Original Message-
> From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
> Sent: Tuesday, March 17, 2020 1:58 AM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org; Zhanghaijian (A)
> Subject: Re: [PATCH PR94026] combine missed opportunity to simplify
Hi,
> -Original Message-
> From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
> Sent: Saturday, March 14, 2020 12:07 AM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org; Zhanghaijian (A)
> Subject: Re: [PATCH PR94026] combine missed opportunity to simp
> -Original Message-
> From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
> Sent: Friday, March 13, 2020 7:50 AM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org; Zhanghaijian (A)
> Subject: Re: [PATCH PR94026] combine missed opportunity to simplify
>
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Thursday, March 5, 2020 11:37 PM
> To: Yangfei (Felix) ; gcc-patches@gcc.gnu.org
> Cc: Zhanghaijian (A)
> Subject: Re: [PATCH PR94026] combine missed opportunity to simplify
> comparisons with zero
Hi,
This is a simple fix for PR94026.
With this fix, combine will try make an extraction if we are in a equality
comparison and this is an AND
with a constant which is power of two minus one. Shift here should be an
constant. For example, combine
will transform (compare (and (lshiftr
> On Mon, Mar 7, 2016 at 7:27 PM, Yangfei (Felix) wrote:
> > Hi,
> >
> > As discussed in LKML:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/355996.html,
> the
> cost of changing a cache line
> > from shared to exclusive state
Hi,
As discussed in LKML:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/355996.html,
the cost of changing a cache line
from shared to exclusive state can be significant on aarch64 cores,
especially when this is triggered by an exclusive store, since it may
result i
accordingly and only accept BUILT_IN_NORMAL string operations.
+
2015-08-18 Segher Boessenkool
Backport from mainline:
>
> On Thu, Aug 20, 2015 at 5:17 AM, Yangfei (Felix)
> wrote:
> > Hi,
> >
> > As DECL_FUNCTION_CODE is overloaded for builtin f
Hi,
As DECL_FUNCTION_CODE is overloaded for builtin functions in different
classes, so need to check builtin class before using fcode.
Patch posted below. Bootstrapped on x86_64-suse-linux, OK for trunk?
Thanks.
Index: gcc/value-prof.c
Patch ping ...
>
> > On 04/02/2015 11:59 PM, Yangfei (Felix) wrote:
> > > Patch ping: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01148.html
> >
> > This patch needs documentation for the new attributes and pragmas
> > before it can be committed. (Si
> On 04/02/2015 11:59 PM, Yangfei (Felix) wrote:
> > Patch ping: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01148.html
>
> This patch needs documentation for the new attributes and pragmas before it
> can be committed. (Since this is a new feature I think it has to wai
Hi Andrew,
Sorry for the late reply. Seems that I misunderstood the AAPCS64
specification.
Thanks for the clarification.
>
> > On Mar 16, 2015, at 2:28 AM, Yangfei (Felix) wrote:
> >
> > Hi,
> >
> > For this trivial testcase:
> >
> >
Patch ping: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01148.html
Thanks.
Hi,
For this trivial testcase:
extern int bar (int , int);
int foo (int *a, int *b)
{
return bar (*a, *b);
}
I noticed that GCC generate redundant zero-extension instructions under ILP32
(aarch64-linux-gnu-gcc -S -O2 -mabi=ilp32).
Assembly code:
.arch armv8-a+fp+simd
.fi
Ping ...
>
> Patch ping: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02258.html
> Any comments, Richard? Thanks.
> On 21/01/15 09:22, Yangfei (Felix) wrote:
> > This is a ping for:
> > https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01008.html
> > I updated the testcase adding test for vfmsq_n_f64 intrinsic.
> > Test OK for both aarch64-linux-gnu and aarch64_be-linux-gnu-gcc.
&g
This is a ping for: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01008.html
I updated the testcase adding test for vfmsq_n_f64 intrinsic.
Test OK for both aarch64-linux-gnu and aarch64_be-linux-gnu-gcc.
OK for the trunk? Thanks.
Index: gcc/ChangeLog
=
Patch ping: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02258.html
Any comments, Richard? Thanks.
Hi,
This is a ping for: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01328.html
OK for the trunk? Thanks.
Hi,
I updated the patch adding one ChangeLog entry.
OK for the trunk? Thanks.
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 219297)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,12 @@
+2015-01-17 Felix Yan
> On 09/12/14 08:17, Yangfei (Felix) wrote:
> >> On 28 November 2014 at 09:23, Yangfei (Felix)
> wrote:
> >>> Hi,
> >>>This patch converts vpmaxX & vpminX intrinsics to use builtin
> >>> functions
> >> instead of the previous i
Hi,
The attached patch does some code cleanup for auto-profile.c: fix typos and
remove some unnecessary MAX/MIN checks plus some "else".
OK for the trunk?
Index: gcc/auto-profile.c
===
--- gcc/auto-profile.c (revision 219297)
> > #define DECL_VABD_VAR(VAR) \
> be careful with your cut and paste. VABD should probably be VFMA_N here,
> although it's purely a naming convention :-)
The v3 patch attached fixed this minor issue. Thanks.
> It's OK for me with that change, but I'm not a maintainer.
>
> O
> On December 16, 2014 9:51:25 AM CET, "Yangfei (Felix)"
> wrote:
> >Hi,
> >
> >This patch fixes an obvious typo which may affect the DDG creation of
> >SMS and make this optimization produce buggy code.
> >Bootstrapped on x86_64-suse-linux. Also
Hi,
This patch fixes an obvious typo which may affect the DDG creation of SMS and
make this optimization produce buggy code.
Bootstrapped on x86_64-suse-linux. Also passed check-gcc test for
aarch64-linux-gnu.
OK for the trunk?
Index: gcc/ddg.c
===
Thanks for reviewing the patch. See my comments inlined:
> > This patch fix this two issues. Three changes:
> > 1. vfma_f32, vfmaq_f32, vfms_f32, vfmsq_f32 are only available for
> arm*-*-* target with the FMA feature, we take care of this through the macro
> __ARM_FEATURE_FMA.
> > 2. vfm
Hi,
This patch add three intrinsics that are required by the ACLE specification.
A new testcase is added which covers vfms_n_f32 and vfmsq_n_f32. Tested on
both aarch64-linux-gnu and aarch64_be-linux-gnu.
OK?
Index: gcc/ChangeLog
===
Hi,
We find that the committed patch is not correctly generated from our local
branch. This caused some code necessary for the testcases missing.
As pointed out by Christophe in
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00778.html, we need to rework the
testcases so that it can work f
> >> >>> +__extension__ static __inline float32x2_t __attribute__
> >> >>> +((__always_inline__))
> >> >>> +vfms_f32 (float32x2_t __a, float32x2_t __b, float32x2_t __c) {
> >> >>> + return __builtin_aarch64_fmav2sf (-__b, __c, __a); }
> >> >>> +
> >> >>> +__extension__ static __inline float32x4_t
> > --- gcc/config/aarch64/aarch64.c(revision 217394)
> > +++ gcc/config/aarch64/aarch64.c(working copy)
> > @@ -10224,6 +10224,9 @@ aarch64_use_by_pieces_infrastructure_p
> (unsigned i
> > #define TARGET_USE_BY_PIECES_INFRASTRUCTURE_P \
> > aarch64_use_by_pieces_infrastructure_p
> >
The definition of function aarch64_function_profiler is removed since GCC-4.9.
But the declaration is still there in aarch64-protos.h. So remove it.
OK for the trunk?
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 218
Hi,
This is a pin for:
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02258.html
Thanks.
> You'll need to rebase over Alan Lawrance's patch.
> https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00279.html
Yes, see my new patch: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00750.html
> > +;; Pairwise Integer Max/Min operations.
> > +(define_insn "aarch64_p"
> > + [(set (match_operand:VQ_
> On 28 November 2014 at 09:23, Yangfei (Felix) wrote:
> > Hi,
> > This patch converts vpmaxX & vpminX intrinsics to use builtin functions
> instead of the previous inline assembly syntax.
> > Regtested with aarch64-linux-gnu on QEMU. Also passed the glorious
&g
> On 5 December 2014 at 18:44, Tejas Belagod wrote:
> >
> >>>
> >>> +__extension__ static __inline float32x2_t __attribute__
> >>> +((__always_inline__))
> >>> +vfms_f32 (float32x2_t __a, float32x2_t __b, float32x2_t __c) {
> >>> + return __builtin_aarch64_fmav2sf (-__b, __c, __a); }
> >>> +
> >>
Any comments? Thanks.
> Hi,
> This patch converts more intrinsics to use builtin functions instead of
> the
> previous inline assembly syntax.
> Passed the glorious testsuite of Christophe Lyon.
>
> Three testcases are added for the testing of intriniscs which are not
> covere
> I've backported this fix to 4.8 & 4.9 branch.
> These patches have been tested for armeb-none-eabi-gcc/g++ with qemu, and
> both the test results were ok.
Looks OK with me. Ramana, is this OK for the 4.8 & 4.9 branches? Thanks.
Hi,
This patch converts vpmaxX & vpminX intrinsics to use builtin functions
instead of the previous inline assembly syntax.
Regtested with aarch64-linux-gnu on QEMU. Also passed the glorious testsuite
of Christophe Lyon.
OK for the trunk?
Index: gcc/ChangeLog
> > On 19/11/14 09:29, Yangfei (Felix) wrote:
> > >>> Sorry for missing the point. It seems to me that 't2' here will
> > >>> conflict with
> > >> condition of the pattern *movhi_insn_arch4:
> > >>> "TARGET_ARM
&g
> On 19/11/14 09:29, Yangfei (Felix) wrote:
> >>> Sorry for missing the point. It seems to me that 't2' here will
> >>> conflict with
> >> condition of the pattern *movhi_insn_arch4:
> >>> "TARGET_ARM
> >>
> > Sorry for missing the point. It seems to me that 't2' here will conflict
> > with
> condition of the pattern *movhi_insn_arch4:
> >"TARGET_ARM
> > && arm_arch4
> > && (register_operand (operands[0], HImode)
> > || register_operand (operands[1], HImode))"
> >
> > #define TA
> On 17 November 2014 06:58, Yangfei (Felix) wrote:
> > PING?
> > BTW: It seems that Alan's way of improving vld1(q?)_dup intrinsic is more
> elegant.
> > So is the improvement of vcls(q?) vcnt(q?) OK for trunk? Thanks.
>
> Please rebase over Alan's
> On Tue, Nov 18, 2014 at 11:51 AM, Yangfei (Felix)
> wrote:
> > Ping again? Any comment please?
>
>
> Pinging daily is only going to irritate people. Please desist from doing so.
>
> Ramana
Oh, thanks for reminding me. And sorry if this bothers you guys.
T
> On 18/11/14 11:02, Yangfei (Felix) wrote:
> >> On 06/11/14 08:35, Yangfei (Felix) wrote:
> >>>>>The idea is simple: Use movw for certain const source
> >>>>> operand instead of
> >>>> ldrh. And exclude the const values whic
Ping again? Any comment please?
>
> Ping? I hope this patch can catch up with stage 1 of GCC-5.0. Thanks.
>
>
>
>
> > > Hi Felix,
> > >
> > > Sorry for the delay responding, I've been out of the office recently
> > > and I'm only just catching up on a backlog of GCC related emails.
> > >
> On 11/18/2014 11:48 AM, Yangfei (Felix) wrote:
> > +(define_expand "doloop_end"
> > + [(use (match_operand 0 "" "")) ; loop pseudo
> > + (use (match_operand 1 "" ""))] ; label
> > + ""
> > +
> On 06/11/14 08:35, Yangfei (Felix) wrote:
> >>> The idea is simple: Use movw for certain const source operand
> >>> instead of
> >> ldrh. And exclude the const values which cannot be handled by
> >> mov/mvn/movw.
> >>> I am
OOP_P
+#define TARGET_CAN_USE_DOLOOP_P can_use_doloop_if_innermost
+
struct gcc_target targetm = TARGET_INITIALIZER;
#include "gt-aarch64.h"
>
> On 17 November 2014 07:59, Yangfei (Felix) wrote:
>
> >> +2014-11-13 Felix Yang
> >> +
> >> + * conf
-folding,
> etc.
> Does that make sense?
>
> --Alan
>
> Yangfei (Felix) wrote:
> >> These three are logically independent, but all on a common theme, and
> >> I've tested them all together by
> >>
> >> bootstrapped + check-gcc on aarch64-none
Hi,
This patch converts more intrinsics to use builtin functions instead of
the previous inline assembly syntax.
Passed the glorious testsuite of Christophe Lyon.
Three testcases are added for the testing of intriniscs which are not
covered by the testsuite:
gcc.target/aar
Ping Richard. Any comments?
> > Hi Felix,
> >
> > Sorry for the delay responding, I've been out of the office recently
> > and I'm only just catching up on a backlog of GCC related emails.
> >
> > I'm in two minds about this; I can potentially see the need for
> > attributes to enable long calls
1 - 100 of 161 matches
Mail list logo
