sure how to create a generic test case, I was checking the
alignment on MIPS by hand by looking for the shift-right/shift-left
instructions that create an aligned pointer but that obviously doesn't
work on other architectures.
Steve Ellcey
sell...@imgtec.com
2015-03-04 Steve Ellcey
_STACK_ALIGNMENT but because
'b' is larger in size than 'c' it gets sorted earlier and its alignment
is used to align the dynamically allocated memory instead of 'c' which
has a greater alignment requirement.
Steve Ellcey
sell...@imgtec.com
int foo(int *x)
align the stack? It seems a lot simpler and more target independent than
what x86 is doing.
Steve Ellcey
sell...@imgtec.com
A pass that inserts __builtin_alloca(8) at front of all routines:
unsigned int
pass_realign_stack::execute (function *fun)
{
basic_block bb;
gimple g;
to the x86 calling convention. No other platform appears
to do dynamic stack alignment.
Steve Ellcey
sell...@imgtec.com
th mips32 and mips64, versions 1, 2, and 6.
With other MIPS versions (mips[1234], r8000, loongson) I did
compilations to assembly language and did a visual inspection of the
code to compare the results before and after this patch was applied.
OK to checkin?
Steve Ellcey
sell...@imgtec.com
2015
I am checking in this change as an obvious fix. When the default int
type as added to main on this test it resulted in 'int int main' for
mips due to the ifdef for mips that is in the code. This patch fixes the
problem.
2015-06-11 Steve Ellcey
* gcc.dg/tree-prof/stringo
for checkin?
Steve Ellcey
sell...@imgtec.com
2015-06-15 Steve Ellcey
* config/mips/mti-linux.h (MIPS_SYSVERSION_SPEC): New.
(SYSROOT_SUFFIX_SPEC): Update.
(SYSROOT_HEADERS_SUFFIX_SPEC): New.
(STARTFILE_PREFIX_SPEC): Update.
* config/mips/t-mti-linux
ists but I didn't dig into exactly
where or what the problem was, I just left the '!' off the default case.
The non-default cases should all have a '!' and I have added it to the
ones that were missing it.
I will check this patch in after I have done one more round of testing
to make sure that my latest changes didn't break anything.
Steve Ellcey
sell...@imgtec.com
img
toolchains I just added a target option to skip them for the mti and img
toolchains.
I ran this by Matthew and got his OK so I will check this patch in along
with the patch to change the sysroot layout.
Steve Ellcey
sell...@imgtec.com
2015-06-16 Steve Ellcey
* gcc.target/mips
ONOR_NAN checks) would have
to wait for the other changes? Here is a new copy with the HONOR_NAN
checks removed from the fused and unfused fma style instructions (and
with comments to explain why it is not needed).
Steve Ellcey
sell...@imgtec.com
2015-06-17 Steve Ellcey
* config.gcc (m
On Wed, 2015-06-17 at 19:17 +0100, Maciej W. Rozycki wrote:
> On Wed, 17 Jun 2015, Steve Ellcey wrote:
>
> FAOD I meant to remove the checks globally throughout MIPS target code
> only.
>
> > Is there any reason why my patch (minus the HONOR_NAN checks) would have
>
h, I found no differences in the generated code.
Here is my "prequel" patch. How does this look?
Steve Ellcey
sell...@imgtec.com
2015-06-17 Steve Ellcey
* config/mips/mips.c (mips_rtx_costs): Remove HONOR_NAN check.
* config/mips/mips.md (*madd4): Ditto.
the
fma/madd instructions).
OK for checkin?
Steve Ellcey
sell...@imgtec.com
2015-06-18 Steve Ellcey
* config.gcc (mips*-*-*): Add fused-madd.opt.
* config/mips/mips.opt (mfused-madd): Remove.
* config/mips/mips.c (mips_rtx_costs): Update cost calculations.
* config
s?
>
> Thanks,
> Matthew
Sorry for the delay (I was on vacation), I fixed up the ChangeLog issues
Maciej pointed out and checked this patch in.
Steve Ellcey
sell...@imgtec.com
I tried compiling an empty plugin that just included gcc-plugin.h and
plugin-version.h and found that these header files were included from
gcc-plugin.h but not in the list of header files to be copied to the
plugin include directory.
OK to checkin?
Steve Ellcey
sell...@imgtec.com
2015-01-14
> >>
> >> 2015-01-14 Steve Ellcey
> >>
> >> * Makefile.in (PLUGIN_HEADERS): Add dominance.h, cfg.h, cfgrtl.h,
> >> cfganal.h, cfgbuild.h, cfgcleanup.h, lcm.h, builtins.def,
> >> chkp-builtins.def, and pass-instance
on mips-mti-linux-gnu.
OK to checkin?
Steve Ellcey
sell...@imgtec.com
2014-10-27 Steve Ellcey
* config/mips/mips.h (ISA_HAS_LDC1_SDC1): Check TARGET_LDC1_SDC1.
* config/mips/mips.md (*__mode == SFmode || TARGET_LDC1_SDC1)"
"\t%0,%1(%2)"
[(set_attr &q
On Mon, 2014-10-27 at 15:32 -0700, Andrew Pinski wrote:
> On Mon, Oct 27, 2014 at 3:23 PM, Steve Ellcey wrote:
> >
> > There are some MIPS patches that have been applied to the Google Android GCC
> > tree but not been submitted to FSF GCC. I would like to get those patc
have emailed my Google contact to see if they could change their
allocator and included a reference to section 7.20.3 of the C standard.
Section 7.20.3 of C99 states: The pointer returned if the allocation
succeeds is suitably aligned so that it may be assigned to a pointer to
any type of object.
Steve Ellcey
everything, but they are needed if building a non-multilib GCC with a
default ABI other than the old 32 bit ABI.
Tested with many builds of mips*-*-linux-gnu targets and various combinations
of --with-arch, --with-abi, --with-endian, --disable-multilib, and
--enable-targets=all.
OK to checkin?
St
ou see a
> need for it then I'd like to see what Catherine thinks.
>
> Thanks,
> Matthew
Here is the patch with the endian support removed, I will go ahead and
check it in.
2014-11-06 Steve Ellcey
* config.gcc (mips*-mti-linux*): Remove gnu_ld and gas assignmen
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
://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
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
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):
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
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"))
>
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-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
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
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
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
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
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
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
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
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
> > >
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 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
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
saved by the caller.
Steve Ellcey
sell...@cavium.com
, 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
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
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
, 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
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
this
patch is OK from that standpoint and fixes an existing problem
on Thunderx2.
Steve Ellcey
) 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
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
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
.
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
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
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.
#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
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
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
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
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 +
> > > &
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
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
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
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
>
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
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
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
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
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 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
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 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
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
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
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
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
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
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
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
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
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
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
; > + 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
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
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
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
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.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
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
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
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
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
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
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
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
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
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. */
>
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
f the fpu header file (fpu-arm.h) that would use the previous
version of support_fpu_trap.
Steve Ellcey
sell...@marvell.com
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
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
;
> 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
201 - 300 of 625 matches
Mail list logo
