nd
> > aarch64-linux-gnu, which took some time.
> >
> > attached v3.
>
> OK.
>
> Thanks,
> Richard.
Dmitrij,
I checked in this patch for you.
Steve Ellcey
sell...@marvell.com
On Wed, 2019-08-07 at 10:40 +, Szabolcs Nagy wrote:
> ---
> ---
> On 31/07/2019 08:25, Richard Sandiford wrote:
> > Steve Ellcey writes:
> > >
> > > 2019-07-30 Steve Ellcey
> > >
> > > * omp-s
need -flto if I
am using -flto-partition? I don't see any description in lto.texi or in
common.opt of exactly what the various values for -flto-partition
(none, one, balanced, 1to1, max) do. Does such a description exist
anywhere?
Steve Ellcey
sell...@marvell.com
On Tue, 2019-08-06 at 16:47 -0400, Marek Polacek wrote:
> On Tue, Aug 06, 2019 at 08:30:14PM +0000, Steve Ellcey wrote:
> > On Tue, 2019-08-06 at 21:04 +0100, Jonathan Wakely wrote:
> > >
> > > The RAJAPerf code appears to be built with -std=gnu++11 which
> > >
same options as the unpreprocessed file,
it does not ICE. I compiled the original file with -save-temps and
that compile no longer gives an ICE. I hate bugs like this.
Steve Ellcey
sell...@marvell.com
Ed,
I have run into an ICE that I tracked down to this patch:
commit 02fefffe6b78c4c39169206aa40fb53f367ecba8
Author: emsr
Date: Thu Aug 1 15:25:42 2019 +
2019-08-01 Edward Smith-Rowland <3dw...@verizon.net>
Implement C++20 p0202 - Add Constexpr Modifiers to Functions
he existing type
> rather than a new one.
>
> > - TREE_TYPE (node->decl) = new_type;
> > -
> >adjustments.release ();
> > }
OK, I fixed that and retested with no regressions.
Steve Ellcey
sell...@marvell.com
2019-07-30 Steve Ellcey
Ping.
Steve Ellcey
sell...@marvell.com
On Mon, 2019-07-22 at 11:25 -0700, Steve Ellcey wrote:
> On Fri, 2019-07-19 at 19:24 +0100, Richard Sandiford wrote:
> >
> > You can probably also remove:
> >
> > tree new_type = build_distinct_type_copy
#x27; is a 32 bit integer
in the default LP64 mode. If I use -mabi=ilp32, then aarch64 does not
generate a warning because both arguments are 32 bits. I could force
ILP32 mode for aarch64 and/or only use -w only when not in 32 bit mode
but that seemed like overkill to me.
OK to checkin?
Steve E
are OK with that change, thanks.
OK, I made that change to the tests.
Latest version of the patch:
2019-07-22 Steve Ellcey
* omp-simd-clone.c (simd_clone_adjust_return_type): Remove call to
build_distinct_type_copy.
(simd_clone_adjust_argument_types): Ditto.
strings about this issue,
pointers to them are in the PR. This patch has already been
suggested by a couple of people (Uros and Christophe) but
never been checked in. Can we go ahead and check it in?
Tested on Aarch64 (ThunderX) with no regressions.
Steve Ellcey
sell...@marvell.com
2019-07-22
.
Retested on x86 and aarch64 with no regressions.
OK to checkin?
Steve Ellcey
sell...@marvell.com
2019-07-19 Steve Ellcey
* omp-simd-clone.c (simd_clone_adjust_return_type): Remove call to
build_distinct_type_copy.
(simd_clone_adjust): Call build_distinct_type_copy
On Thu, 2019-07-18 at 08:37 +0100, Richard Sandiford wrote:
>
> > 2019-07-17 Steve Ellcey
> >
> > * omp-simd-clone.c (simd_clone_adjust): Call targetm.simd_clone.adjust
> > after calling simd_clone_adjust_return_type.
> > (expand_simd_clones): Dit
tform that this patch could affect is x86 because that is
the only other platform to use targetm.simd_clone.adjust. I did a
bootstrap and gcc test run on x86 (as well as Aarch64) and got no
regressions.
OK to checkin?
Steve Ellcey
sell...@marvell.com
2019-07-17 Steve Ellcey
* omp-si
) ones?
This is obviously a question for the pre-SVE vector instructions,
I am not sure how this would be handled in SVE.
Steve Ellcey
sell...@marvell.com
P.S. Here a test case in Fortran that generated the 2 element
vector call. It unrolled the loop into one vector call
of 2 elements
no objection to the change but could the commit message and/or
comments be expanded to explain the ':12' part of this value. I
couldn't find an explanation for it in the code and I don't understand
what it does.
Steve Ellcey
sell...@marvell.com
it/config/fetch/checkout commands. After the
conversion will we be able to just use 'git clone'? And will the
default master branch be the usable GCC top-of-tree sources (vs the
trunk branch) that we can do checkins to?
Steve Ellcey
sell...@marvell.com
Re-ping. I know there are discussions about bigger changes to fix the
various failures listed in PR rtl-optimization/87763 but this patch
at least fixes one of them (gcc.target/aarch64/lsl_asr_sbfiz.c).
Steve Ellcey
sell...@marvell.com
On Wed, 2019-04-10 at 15:35 -0700, Steve Ellcey wrote
rand 3 instead of operand 1 and
that caused a couple of test failures. I fixed it and the regressions
went away. I also had to tweak gcc.target/aarch64/combine_bfxil.c,
some of the bfxil instructions became bfi instructions so I updated
the scan checks.
Steve Ellcey
On Thu, 2019-04-11 at 14:58 +, Steve Ellcey wrote:
>
> > You've removed the ..._noshift_alt variant. That wasn't my
> > intention,
> > so perhaps you misunderstood what I was trying to say.
> >
> > The two versions are both needed, since th
On Thu, 2019-04-11 at 09:59 +0100, Richard Earnshaw (lists) wrote:
>
> >
> > 2018-04-10 Steve Ellcey
> >
> > PR rtl-optimization/87763
> > * config/aarch64/aarch64-protos.h
> > (aarch64_masks_and_shift_for_bfi_p):
> > New
On Wed, 2019-04-10 at 15:03 -0700, Steve Ellcey wrote:
> Here is another patch to fix one of the failures
> listed in PR rtl-optimization/87763. This change
> fixes gcc.target/aarch64/lsl_asr_sbfiz.c by adding
> an alternative version of *ashiftsi_extv_bfiz that
> has a subreg in
Ellcey
2018-04-10 Steve Ellcey
PR rtl-optimization/87763
* config/aarch64/aarch64.md (*ashiftsi_extv_bfiz_alt):
New Instruction.
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index e0df975..04dc06f 100644
--- a/gcc/config/aarch64/aarch64.md
On Wed, 2019-04-10 at 11:10 +0100, Richard Earnshaw (lists) wrote:
>
> OK with those changes.
>
> R.
I made the changes you suggested and checked in the patch. Just to be
complete, here is the final version of the patch that I checked in.
2018-04-10 Steve Ellcey
to get feedback on bugfix patches.
Steve Ellcey
sell...@marvell.com
2018-04-01 Steve Ellcey
PR rtl-optimization/87763
* config/aarch64/aarch64-protos.h (aarch64_masks_and_shift_for_bfi_p):
New prototype.
* config/aarch64/aarch64.c
Double ping.
Steve Ellcey
sell...@marvell.com
On Tue, 2019-02-26 at 08:44 -0800, Steve Ellcey wrote:
> Ping.
>
> Steve Ellcey
> sell...@marvell.com
>
>
> On Mon, 2019-02-11 at 10:46 -0800, Steve Ellcey wrote:
> > On Thu, 2019-02-07 at 18:13 +, Wilco Dijkstra
y
address the issue of the scalar and vector variants being independent
of each other but it does make the problem moot in this specific case.
Steve Ellcey
sell...@marvell.com
On Tue, 2019-03-12 at 14:17 +, Joseph Myers wrote:
>
> On Tue, 12 Mar 2019, Richard Biener wrote:
>
> > It shouldn't be difficult to provide an alias from the glibc side, no?
> > How does x86 avoid this issue?
>
> There are static-only wrappers in libmvec_nonshared.a to work around the
>
g00213.html
Any thoughts on this patch as a way of 'fixing' GCC to not use the
finite alias names?
Steve Ellcey
sell...@marvell.com
2018-03-11 Steve Ellcey
* config/aarch64/aarch64.c (aarch64_simd_clone_vec_base_name):
New function.
(TARGET_SIMD_CLONE_VEC_B
ORDER only affects Aarch64 and seems like a safer change.
I am not sure how long it would take me to implement something along
the lines of what you are suggesting.
Steve Ellcey
sell...@marvell.com
On Sat, 2019-03-09 at 08:03 +, Richard Sandiford wrote:
> Steve Ellcey writes:
> > T
eckin?
2018-03-08 Steve Ellcey
PR target/89628
* config/aarch64/aarch64.h (V16-V31): Update comment.
(REG_ALLOC_ORDER): New macro.
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 7bd3bf5..d3723ff 100644
--- a/gcc/config/aarch64/aarc
Ping.
Steve Ellcey
sell...@marvell.com
On Mon, 2019-02-11 at 10:46 -0800, Steve Ellcey wrote:
> On Thu, 2019-02-07 at 18:13 +, Wilco Dijkstra wrote
> >
> > Hi Steve,
> >
> > > > After special cases you could do something like t = mask2 +
> > > &
Thanks,
> Richard
OK, here is a new patch with the ILP32 and big-endian conditions still
in place but the sve stuff removed. Retested on aarch64 with no
regressions. OK for checkin?
Steve Ellcey
sell...@marvell.com
2018-02-26 Steve Ellcey
* config/aarch64/aarch64.c (aarch64
call SVE vector functions. So right
now this would always return false, until such time as GCC is changed
to do calls with SVE vectors as arguments.
Given that it would always return false I guess we could just drop it
out for now.
Steve Ellcey
sell...@marvell.com
FYI: If anyone is interested here
it seemed better to have them and not use them
than to find out we need them later.
Tested on Aarch64 and x86 with bootstraps and test runs. There were no
regressions.
Ok to checkin?
Steve Ellcey
sell...@marvell.com
2018-02-19 Steve Ellcey
* config/aarch64/aarch64.c
multilib_abi_name target function for that platform. Everything
seemed to work fine for me and I did not have any problems or see any
regressions when using your patch. I hope it gets approved and checked
in soon.
Steve Ellcey
sell...@marvell.com
r an error because the testsuite adds -pedantic-
errors to the compile line. Without this you would just get a warning,
but that is consistent with any mixing of different function types in a
function pointer assignment.
Tested with a bootstrap build and test run on aarch64. OK for checkin?
Steve E
;
> void (*g)(void) = f;
>
> without a warning (treats function types with different
> pcs as compatible)
>
> i think we don't want to allow calls through the wrong
> pointer type, such assignment should be an error.
I agree. I will submit a patch to change the affects_type_identity
flag and add a test for it.
Steve Ellcey
sell...@marvell.com
as expected), but I
> can't approve.
>
> Wilco
Thanks for looking this over. I have updated the mask check to use
your method and retested to make sure it still works. Can one of the
aarch64 maintainers approve this patch?
2018-02-11 Steve Ellcey
PR rtl-optimizati
x27; choice in that it would say we do not support this on some
machines where it actually is supported but it would no longer claim
support on a machine where it is not supported.
Steve Ellcey
sell...@marvell.com
f the fpu header file (fpu-arm.h) that would use the previous
version of support_fpu_trap.
Steve Ellcey
sell...@marvell.com
oblem. Sign
extension?
> Finally from some quick testing it seems one case is not yet
> supported:
>
> int f1(int x, int y)
> {
> return (y & 0xfff) | (((x <<28) & 0xf000));
> }
>
> This just has a shift, rather than an AND plus a shift.
I add
Ping. And adding Aarch64 Maintainers.
On Mon, 2019-01-28 at 16:11 -0800, Steve Ellcey wrote:
> On Sat, 2019-01-26 at 00:00 +0100, Jakub Jelinek wrote:
> >
> > > + /* Verify that there is no overlap in what bits are set in the
> > > two masks. */
>
add an new
instruction like *ashiftsi_extv_bfiz but with the subregs. This fixes
lsl_asr_sbfiz.c. Does this seem like the right way to fix this?
Steve Ellcey
sell...@marvell.com
2018-01-29 Steve Ellcey
PR rtl-optimization/87763
* config/aarch64/aarch64.md (*ashiftsi_ext
stant or that
it would check both orderings.
I tried adding a second version of *aarch64_bfi5_shift as
well but when I tested it, it never got used during a bootstrap build
or a GCC test run so I decided it was not needed.
Tested on aarch64 with a bootstrap build and a GCC testsuite run.
OK to
because with my new instructions we
sometimes generate bfi instructions where we used to generate bfxil
instructions. The only regression this is fixing is combine_bfi_1.c,
combine_bfxil.c was passing before but still needed to be changed in
order to keep passing.
Steve Ellcey
sell...@marvell.c
s and if this seems like
a reasonable approach.
Steve Ellcey
sell...@marvell.com
2018-01-24 Steve Ellcey
PR rtl-optimization/87763
* config/aarch64/aarch64-protos.h
(aarch64_masks_and_shift_for_aarch64_bfi_p): New prototype.
* config/aarch64/aarc
to be part of this patch though, I could submit one later if you
do not want to add it here.
Aarch64 ILP32 support is in GCC and binutils but not GLIBC (except on a
branch), I am thinking the Aarch64 version of this function would
return "aarch64" or "aarch64_ilp32". Perhaps we should also have
"aarch64_be" and "aarch64_be_ilp32" for big endian ABI's?
Steve Ellcey
sell...@marvell.com
On Wed, 2019-01-23 at 23:53 +0100, Jakub Jelinek wrote:
> External Email
>
> ---
> ---
> On Wed, Jan 23, 2019 at 09:56:21PM +0000, Steve Ellcey wrote:
> > I wonder if we even need to pass a string to the targ
can just return true, target specific versions could look at the ABI and
return true or false as needed.
It might also be worth passing the function (cos) as an argument to the
target function, then we could have different ABI's enabling different
functions and not have to have them all on or
ad. I didn't see any patch submitted
in response to your comment there so I created a new patch.
This patch leaves the assert in aarch64.c and changes the check
for the 'p' constraint in constain_operands, this version
fixes the pr84682-2.c test failure and causes no regressions
aarch64.c. Bin submitted a followup:
https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01166.html
But there were no replies to that patch submission. I have retested
the second patch and verified it fixes the aarch64 failure and causes
no regressions on aarch64 or x86.
OK to checkin?
Steve Ellcey
upport gomp.
>
> I'm happy to update them for you if you want though.
I already updated them. Thanks for checking on the failures.
Steve Ellcey
sell...@cavium.com
aarch64*-*-*' instead of 'aarch64-*-*' since that seems to be the
standard method (though I see a few other tests that are not using
aarch64 instead of aarch64*).
I guess that while you are testing big-endian the target triplet you
are using is still aarch64-*-* and not aarch64be-*-*? Otherwise I
would have expected you to have more failures.
Steve Ellcey
sell...@marvell.com
I haven't tested this, I don't have an ILP32 build sitting around right
now. Does it work for you? I can build a toolchain, test it, and
submit a patch if you want.
Steve Ellcey
sell...@marvell.com
he warning is not
generated.
The fix is just to add the target check to the new warnings I added earlier
today.
Sorry for the noise.
Steve Ellcey
sell...@marvell.com
2018-01-17 Steve Ellcey
PR fortran/88898
* gfortran.dg/gomp/declare-simd-2.f90: Add aarch64 target sp
; > + return 0;
>
> The return should use tab indentation.
Fixed.
>
> OK otherwise, thanks.
>
> Richard
Thanks for the reviews Richard, I made those changes and checked in the
patch. That is the last of the Aarch64 SIMD / Vector ABI patches I
have so everyt
er, I think returning 2 instead of 1 is what was
causing the ICE. I used your code to set the return value and the
vecsize and everything works now.
Here is a new version of the patch, it bootstraps on aarch64 and x86
and the GCC testsuite ran with no regressions on both platforms as
well.
Ste
versions to you to see if you had any ideas on the problems
I am seeing.
Steve Ellcey
sell...@marvell.com
Here are the failures I am getting with this patch:
c-c++-common/gomp/pr63328.c
gcc.dg/gomp/pr87895-2.c
These tests include another test (which passes) and the included tests
have a dg-warning
d for
> > type %qT",
> > + clonei->simdlen, base_type);
> > + return 0;
> > +}
>
> nit: block contents indented too far.
Fixed.
> > + return 0;
> > +}
>
> Doesn't this mean that we always silently fail for an
which is Aarch64 specific.
https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01421.html
Jakub had some comments on the test changes which I fixed but I did
not get any feedback on the actual code changes so I am not sure if
that is OK or not.
STeve Ellcey
sell...@marvell.com
at patches that were
initially submitted during Stage 1 could go ahead once approved.
Steve Ellcey
sell...@marvell.com
2019-01-10 Steve Ellcey
* config/aarch64/aarch64.c (aarch64_simd_call_p): New function.
(aarch64_hard_regno_call_part_clobbered
implement the calls_have_same_clobbers_p
function other than doing that.
Steve Ellcey
sell...@marvell.com
2019-01-09 Steve Ellcey
* config/aarch64/aarch64.c (aarch64_simd_call_p): New function.
(aarch64_hard_regno_call_part_clobbered): Add ins
rguments to hard_regno_call_part_clobbered but I think they should
be OK. I believe I addressed all the issues you brought up. The ones
I am least confident of are the lra-lives.c changes. I think they are
right and testing had no regressions, but they are probably the changes
that need to be checked most closely.
S
le I am testing it (including building
some of the other targets).
Steve Ellcey
sell...@cavium.com
2019-01-04 Steve Ellcey
* config/aarch64/aarch64.c (aarch64_simd_call_p): New function.
(aarch64_hard_regno_call_part_clobbered): Add ins
TARGET_REMOVE_EXTRA_CALL_PRESERVED_REGS build correctly.
Steve Ellcey
sell...@marvell.com
2019-01-02 Steve Ellcey
* config/aarch64/aarch64.c (aarch64_simd_call_p): New function.
(aarch64_remove_extra_call_preserved_regs): New function.
(TARGET_REMOVE_EXTRA_CALL_PRESERVED_REGS): New macro
numbers. I also moved the warning checks to be closer
to the lines where the warnings are generated.
Retested on x86 and aarch64 with no regressions.
Steve Ellcey
sell...@cavium.com
2018-12-21 Steve Ellcey
* g++.dg/gomp/declare-simd-1.C: Add aarch64 specific
warning checks
On Wed, 2018-12-19 at 23:57 +0100, Jakub Jelinek wrote:
> On Wed, Dec 19, 2018 at 10:10:19PM +0000, Steve Ellcey wrote:
> > @@ -199,6 +201,7 @@ int B::f25<7> (int a, int *b, int c)
> > // { dg-final { scan-assembler-times
> > "_ZGVdN8vuva32u__ZN1BIiE3f25
to) differentiate
between vectors that we are not currently handling (but could later) and
those that won't ever be handled.
I have also added a testsuite patch to fix regressions in the gcc.dg/gomp
and g++.dg/gomp tests. There are no regressions with this patch applied.
Steve Ellcey
On Wed, 2018-12-12 at 11:39 +, Richard Sandiford wrote:
>
> Steve Ellcey writes:
> > On Fri, 2018-12-07 at 17:34 +, Richard Sandiford wrote:
> > > > + (match_operand:TX 2 "register_operand" "w"))
>
gument.
> You should be able to just check node->definition whether it is a
> definition
> or declaration.
>
> Jakub
You are right, I can just use node->definition and not add the new
argument. I will make that change.
Steve Ellcey
sell...@cavium.com
arch64.
Steve Ellcey
sell...@marvell.com
2018-12-11 Steve Ellcey
* config/aarch64/aarch64.c (cgraph.h): New include.
(aarch64_simd_clone_compute_vecsize_and_simdlen): New function.
(aarch64_simd_clone_adjust): Ditto.
(aarch64_simd_clone_usable):
perands[4]) + GET_MODE_SIZE
> > (mode)"
>
> && should be on the second line (which makes the line long enough to
> need breaking).
Fixed.
>
> > diff --git a/gcc/testsuite/gcc.target/aarch64/torture/simd-abi-2.c
> >
>
> Comment d
://gcc.gnu.org/ml/gcc-patches/2018-11/msg00641.html
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00642.html
Steve Ellcey
sell...@marvell.com
this
patch is OK from that standpoint and fixes an existing problem
on Thunderx2.
Steve Ellcey
ink this should
be documented so flang and other compilers can use it. Even if no
other compilers did use it I think it should be documented because it
crosses project/package boundries, i.e. it is created by glibc and used
by gfortran.
Steve Ellcey
sell...@cavium.com
, but if we can determine
that the function will not do any partial clobbers (like the
Aarch64 SIMD functions) then it returns false.
Steve Ellcey
sell...@cavium.com
2018-11-08 Steve Ellcey
* config/aarch64/aarch64.c (aarch64_check_part_clobbered): New function
some registers that normal functions
do not. The default version of this function will do nothing.
Steve Ellcey
sell...@cavium.com
2018-11-08 Steve Ellcey
* config/aarch64/aarch64.c (aarch64_simd_call_p): New function.
(aarch64_remove_extra_call_preserved_regs): New function
This is a patch 2 to support the Aarch64 SIMD ABI [1] in GCC.
It defines the TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN,
TARGET_SIMD_CLONE_ADJUST, and TARGET_SIMD_CLONE_USABLE macros
so that GCC can generate SIMD clones on aarch64.
Steve Ellcey
sell...@cavium.com
2018-11-08 Steve Ellcey
, but it is correct code. Patches 3 and 4 will remove the extra
saves from the caller.
Steve Ellcey
sell...@cavium.com
2018-11-08 Steve Ellcey
* config/aarch64/aarch64-protos.h (aarch64_use_simple_return_insn_p):
New prototype.
(aarch64_epilogue_uses): Ditto
saved by the caller.
Steve Ellcey
sell...@cavium.com
an extra instruction in each of the
routines. Here is an example from one function where there is an
extra fmov that was not there before. The test runs at -O1 but
the extra instruction appears at all optimization levels. Should
I submit a new PR for this?
Steve Ellcey
void cvt_int32_t_to_float
arch64_epilogue_uses was not saving extraneous registers. While
that function returns true for all vector registers that a SIMD
function must save, only registers that are used/clobbered in the
function will be saved. That is now tested with the simd-abi-5.c
test.
Steve Ellcey
sell...@cavium.com
Ping. If I don't hear any objections I will consider this patch as
obvious since the only change is to add noinline attributes to the
tests.
Steve Ellcey
sell...@cavium.com
On Wed, 2018-09-26 at 09:21 -0700, Steve Ellcey wrote:
> A patch for PR tree-optimized/71625 caused regression
this fixed the test regressions.
Tested on aarch64, OK for checkin?
Steve Ellcey
sell...@cavium.com
2018-09-26 Steve Ellcey
PR tree-optimization/71625
* /gcc.target/aarch64/vclz.c (test_vclz_s8): Add noinline attribute.
(test_vclz_s16): Ditto.
(test_vclz_s32
nse for aarch64 anymore and I would like to just not
run it on aarch64.
Tested on aarch64. OK for checkin?
Steve Ellcey
sell...@cavium.com
2018-09-26 Steve Ellcey
PR testsuite/87433
* gcc.dg/zero_bits_compound-1.c: Do not run on aarch64*-*-*.
diff --git a/gcc/t
asr instructions instead of 4. Given that the overall test now has
two fewer instructions and appears to be superior to the original generated
code, this patch just updates the test to reflect the newly generated code.
Tested on aarch64, OK for checkin?
Steve Ellcey
sell...@cavium.com
2018-09
use registers it knows the vector sin/log/exp functions do not clobber.
Comments?
Steve Ellcey
sell...@cavium.com
2018-09-20 Steve Ellcey
* caller-save.c (setup_save_areas): Modify get_call_reg_set_usage
arguments.
(save_call_clobbered_regs): Ditto.
tested yet but is fairly
safe and I am posting it to see if there are any comments on it.
Steve Ellcey
sell...@cavium.com
2018-09-20 Steve Ellcey
* config/aarch64/aarch64.c (cgraph.h): New include.
(aarch64_simd_clone_compute_vecsize_and_simdlen): New function
. The other two are not fully tested but are being
submitted for to get feedback.
Steve Ellcey
sell...@cavium.com
2018-09-20 Steve Ellcey
* config/aarch64/aarch64-protos.h (aarch64_use_simple_return_insn_p):
New prototype.
(aarch64_epilogue_uses): Ditto
On Tue, 2018-09-04 at 17:20 +, Wilco Dijkstra wrote:
> External Email
>
> Hi Steve,
>
> The latest version compiles the examples I used correctly, so it looks fine
> from that perspective (but see comments below). However the key point of
> the ABI is to enable better code generation when cal
Ping. Any feedback from the Aarch64 maintainers?
Steve Ellcey
sell...@cavium.com
On Mon, 2018-08-20 at 10:37 -0700, Steve Ellcey wrote:
> On Tue, 2018-08-07 at 12:15 -0500, Segher Boessenkool wrote:
>
> >
> > >
> > > +/* { dg-final { scan-assemble
On Mon, 2018-08-27 at 10:27 -0600, Jeff Law wrote:
> External Email
>
> On 08/27/2018 09:55 AM, Steve Ellcey wrote:
> >
> > On Sun, 2018-08-26 at 20:56 -0600, Jeff Law wrote:
> > >
> > > MIPS builds have been failing to build due to trying to use an
>
t; jeff
I tried this change in gcc/config/aarch64/aarch64-speculation.cc
(changing include of cfg.h to backend.h) and it fixed my build problem.
Steve Ellcey
type ‘struct function’
: auto_flag (&fun->cfg->edge_flags_allocated) {}
It looks like this may be Aarch64 specific build problem since it is
compiling a platform specific file. Is there just a missing include?
Steve Ellcey
sell...@cavium.com
ne. Since
there are some uses of non consecutive numbers in one of the tests I
decided to leave [01234567] instead of using [0-7]. Here is the
latest version of the patch, there are no semantic changes, just
syntactical ones to address the issues that you pointed out.
Steve Ellcey
sell...@
dispatch is different
than issue but I don't think that GCC models both. For my patch
I would probably want to save the previous instruction scheduled so
that if it and the current one are both FP/SIMD ops, then that is all
we can issue. I might need to save several instructions, not just the
last one, to get everything correct.
Steve Ellcey
sell...@cavium.com
deas on where should this check be done, I thought the
TARGET_OPTION_VALID_ATTRIBUTE_P hook might be the right place, but that
seems to be specific to the 'target' attribute only, not attributes
in general.
Steve Ellcey
sell...@cavium.com
that works but it does. I copied the aarch64-torture.exp
file from one of the other targets and verified that it ran the
tests with -O0, -O1, -O2, '-O3 -g', -Os, '-O2 -flto -fno-use-linker-
plugin -flto-partition=none', and '-O2 -flto -fuse-linker-plugin -fno-
fat-lt
registers will also be
saved by the callee.
Steve Ellcey
sell...@cavium.com
[1] https://developer.arm.com/products/software-development-tools/hpc/a
rm-compiler-for-hpc/vector-function-abi
Compiler ChangeLog:
2018-07-31 Steve Ellcey
* config/aarch64/aarch64-protos.h
1 - 100 of 625 matches
Mail list logo
