from:"Moore, Catherine"

[OG10] Reverted patch on OG10 branch

2021-02-16 Thread Moore, Catherine

FYI - I reverted this patch:

commit ea43db9372133e84f95bdb2c6934a5cc3db3d530
Author: Catherine Moore 
Date:   Sat Feb 13 09:04:44 2021 -0800

Revert "Enable gimplify GOMP_MAP_STRUCT handling of (COMPONENT_REF 
(INDIRECT_REF ...)) map clauses."

This reverts commit bf8605f14ec33ea31233a3567f3184fee667b695.

Regressions were reported for BZ 9574 - C++ class member mapping.

RE: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC

2020-07-12 Thread Moore, Catherine



>-Original Message-
>From: Gcc-patches [mailto:gcc-patches-boun...@gcc.gnu.org] On Behalf
>Of Tom de Vries
>Sent: Friday, July 3, 2020 6:52 AM
>To: Moore, Catherine ; Burnus, Tobias
>; gcc-patches ;
>Jakub Jelinek 
>Cc: Schwinge, Thomas ; Stubbs,
>Andrew 
>Subject: Re: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC
>
>On 6/26/20 9:35 PM, Moore, Catherine wrote:
>> Hi Tom,
>>
>> It doesn't look like you were explicitly cc'd on this patch and probably
>haven't seen it.  Would you mind taking a look and approving the nvptx
>portions?
>>
>
>[ thanks for the ping, I think was explicitly cc-ed though.  I'm usually
>not too fast in reviewing, and this time a vacation added to that. ]
>
>The patch looks good to me.

Thanks for the review.
Catherine

>
>I tried out the patch with one test-case and -pie -fPIC/-fpic already
>seems to works, so perhaps we could have at least one test-case
>exercising this in libgomp?  That sounds easier to do than the
>shared-lib test-case.
>
>I think it's a good idea though to do fPIE/fpie as well, either in this
>patch or as follow-up.
>
>Thanks,
>- Tom
>
>> Thanks,
>> Catherine
>>
>>> -Original Message-
>>> From: Gcc-patches [mailto:gcc-patches-boun...@gcc.gnu.org] On
>Behalf
>>> Of Burnus, Tobias
>>> Sent: Tuesday, June 23, 2020 11:21 AM
>>> To: gcc-patches ; Jakub Jelinek
>>> 
>>> Cc: Stubbs, Andrew ; Schwinge,
>Thomas
>>> 
>>> Subject: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC
>>>
>>> If the offloading code is (only) in a library, one can come up
>>> with the idea to build those parts as shared library – and link
>>> it to the nonoffloading code.(*)
>>>
>>> Currently, this fails as the mkoffload calls the nonoffloading
>>> compiler without the -fpic/-fPIC flags, even though the compiler
>>> was originally invoked with those options. – And at some point,
>>> the linker then complains.
>>>
>>> This patch simply adds -fpic/-fPIC to the calls to the nonoffloading
>>> ("host") compiler, invoked from mkoffload, if they were present before.
>>>
>>> For the testcase at hand, this works with both AMDGCN and nvptx
>>> with the attached patch.
>>>
>>> OK for the trunk?
>>>
>>> Tobias
>>>
>>> PS: I think as mid-/longterm project it would be nice to test this
>>> in the testsuite, but that's unfortunately a larger task.
>>>
>>> (*) Thomas mentioned that this is supposed to work also in more
>>> complex cases than the one I outlined, although, that is probably
>>> currently the most common one.
>>>
>>> -
>>> Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634
>München /
>>> Germany
>>> Registergericht München HRB 106955, Geschäftsführer: Thomas
>Heurung,
>>> Alexander Walter

RE: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC

2020-06-26 Thread Moore, Catherine

Hi Tom,

It doesn't look like you were explicitly cc'd on this patch and probably 
haven't seen it.  Would you mind taking a look and approving the nvptx portions?

Thanks,
Catherine

>-Original Message-
>From: Gcc-patches [mailto:gcc-patches-boun...@gcc.gnu.org] On Behalf
>Of Burnus, Tobias
>Sent: Tuesday, June 23, 2020 11:21 AM
>To: gcc-patches ; Jakub Jelinek
>
>Cc: Stubbs, Andrew ; Schwinge, Thomas
>
>Subject: [Patch][gcn, nvptx, offloading] mkoffload – handle -fpic/-fPIC
>
>If the offloading code is (only) in a library, one can come up
>with the idea to build those parts as shared library – and link
>it to the nonoffloading code.(*)
>
>Currently, this fails as the mkoffload calls the nonoffloading
>compiler without the -fpic/-fPIC flags, even though the compiler
>was originally invoked with those options. – And at some point,
>the linker then complains.
>
>This patch simply adds -fpic/-fPIC to the calls to the nonoffloading
>("host") compiler, invoked from mkoffload, if they were present before.
>
>For the testcase at hand, this works with both AMDGCN and nvptx
>with the attached patch.
>
>OK for the trunk?
>
>Tobias
>
>PS: I think as mid-/longterm project it would be nice to test this
>in the testsuite, but that's unfortunately a larger task.
>
>(*) Thomas mentioned that this is supposed to work also in more
>complex cases than the one I outlined, although, that is probably
>currently the most common one.
>
>-
>Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München /
>Germany
>Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung,
>Alexander Walter

[Committed] Remove myself as MIPS maintainer

2018-04-25 Thread Moore, Catherine

2018-04-25  Catherine Moore 

* MAINTAINERS (mips): Remove myself as MIPS maintainer.

RE: [PATCH] Fix mips hang with --help=target --help=optimizers (PR target/82880)

2017-11-21 Thread Moore, Catherine



> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Tuesday, November 21, 2017 9:07 AM
> To: Moore, Catherine <catherine_mo...@mentor.com>; Matthew
> Fortune <matthew.fort...@imgtec.com>
> Cc: gcc-patches@gcc.gnu.org; James Cowgill
> <james.cowg...@imgtec.com>
> Subject: [PATCH] Fix mips hang with --help=target --help=optimizers (PR
> target/82880)
> 
> Hi!
> 
> This is a patch from James that has been sitting in bugzilla for a few
> weeks.  The bug is that mips_register_frame_header_opt registers
> the pass from a static variable which has an automatic variable in the
> initializer, which means that the first time it is called it is registered
> properly, but if it is called multiple times (e.g. possible with gccjit
> or multiple --help options), then the second time it creates a new pass,
> but registers with the old pass (since the var isn't initialized again).
> register_pass doesn't store the address it is called with anywhere, just
> uses the fields of the struct and stores the pass (first field).
> All other spots that call register_pass in all backends do it properly
> it seems.
> 
> I've just fixed up formatting and added a testcase, tested with cross to
> mips and tested the testcase on x86_64-linux and i686-linux.
> 
> Ok for trunk?
> 
> 2017-11-21  James Cowgill  <james.cowg...@imgtec.com>
>   Jakub Jelinek  <ja...@redhat.com>
> 
>   PR target/82880
>   * config/mips/frame-header-opt.c
> (mips_register_frame_header_opt):
>   Remove static keyword from f variable.
> 
>   * gcc.dg/opts-8.c: New test.
> 
Yes, this is OK.  Thanks for fixing.

RE: [patch, MIPS] Update -mvirt option description

2017-04-06 Thread Moore, Catherine



> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Friday, March 31, 2017 4:00 PM
> To: Moore, Catherine <catherine_mo...@mentor.com>
> Cc: 'gcc-patches@gcc.gnu.org' (gcc-patches@gcc.gnu.org)  patc...@gcc.gnu.org>; roland.il...@gmx.de
> Subject: [patch, MIPS] Update -mvirt option description
> 
> Hi Catherine,
> 
> I'm following up on PR target/80057 to update the description of -
> mvirt.
> 
> I agree with Roland that the description is inconsistent and should not
> state 'application specific' as none of the other ASE options include
> it. Instead I suggest we put the shortened form of (VZ) in like (XPA)
> is shown for -mxpa. The short form of virtualization ASE is usually VZ
> not VIRT which has always irritated me about this option name but
> that
> is history.
> 
> What do you think?

This looks good to me.
> 
> gcc/
>   PR target/80057
>   * config/mips/mips.opt (-mvirt): Update description.
>

RE: [PATCH] Fix MIPS-specific ICE in gcc.dg/pr77834.c (PR rtl-optimization/79150).

2017-03-20 Thread Moore, Catherine



> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Wednesday, March 15, 2017 11:30 AM
> To: Moore, Catherine <catherine_mo...@mentor.com>
> Cc: Segher Boessenkool (seg...@kernel.crashing.org)
> <seg...@kernel.crashing.org>; Toma Tabacu
> <toma.tab...@imgtec.com>; gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH] Fix MIPS-specific ICE in gcc.dg/pr77834.c (PR rtl-
> optimization/79150).
> 
> Hi Catherine,
> 
> What is your opinion on this patch? I am OK with the temporary
> workaround on the basis that the additional nop is successfully
> eliminated so there is no code size increase. Also, I am happy
> enough that the CFG is fixed very soon after the block move is
> expanded so the 'bad' basic block is fixed almost immediately
> anyway making the offending check potentially unnecessary in
> the first place.
> 
I'm okay with the workaround for stage 4, but would like to see the pr remain 
open until a proper fix is installed on trunk. 
Toma, would you be able to pursue the original patch that you attached to the 
bug report?

Catherine
> 
> > -Original Message-
> > From: Toma Tabacu
> > Sent: 07 March 2017 11:44
> > To: gcc-patches@gcc.gnu.org
> > Cc: Matthew Fortune; Segher Boessenkool
> (seg...@kernel.crashing.org)
> > Subject: [PATCH] Fix MIPS-specific ICE in gcc.dg/pr77834.c (PR rtl-
> > optimization/79150).
> >
> > Hi,
> >
> > This ICE is caused by "gcc_assert (!JUMP_P (last))" in
> > commit_one_edge_insertion (gcc/cfgrtl.c):
> >
> >   if (returnjump_p (last))
> > {
> >   /* ??? Remove all outgoing edges from BB and add one for EXIT.
> >  This is not currently a problem because this only happens
> >  for the (single) epilogue, which already has a fallthru edge
> >  to EXIT.  */
> >
> >   e = single_succ_edge (bb);
> >   gcc_assert (e->dest == EXIT_BLOCK_PTR_FOR_FN (cfun)
> >   && single_succ_p (bb) && (e->flags &
> EDGE_FALLTHRU));
> >
> >   e->flags &= ~EDGE_FALLTHRU;
> >   emit_barrier_after (last);
> >
> >   if (before)
> > delete_insn (before);
> > }
> >   else
> > gcc_assert (!JUMP_P (last));
> >
> > The assert is triggered because we're removing an edge which ends on a
> > conditional jump, which is part of a loop.
> >
> > The reason for the existence of this loop is the size of the vector used
> > in gcc.dg/pr77834.c.
> > When compiling code which uses vectors for MIPS, a looping memcpy is
> > generated if the vectors are big enough (>32 bytes for MIPS32 or >64
> > bytes for MIPS64).
> > This takes place in mips_expand_block_move (gcc/config/mips.c).
> >
> > In our case, a looping memcpy gets generated for a partition copy
> which
> > is inserted on an edge (in insert_partition_copy_on_edge, gcc/tree-
> > outof-ssa.c).
> > This happens during PHI node elimination, which is done by
> eliminate_phi
> > (gcc/tree-outof-ssa.c), as a part of expand_phi_nodes, which is called
> > by the expand pass (gcc/cfgexpand.c).
> >
> > My original fix was to update the CFG by calling
> > find_many_sub_basic_blocks with an all-one block bitmap (which also
> > happens in cfgexpand.c, after edge
> > removal) whenever an edge contains an insn which satisfies
> > control_flow_insn_p.
> > However, Segher Boessenkool said that this would be too risky for stage
> > 4 and suggested inserting a NOP after the conditional jump in order to
> > fool the assert. This assumes that it is safe to delay the CFG update
> > for this particular case.
> >
> > This patch changes mips_block_move_loop to emit a NOP after the
> > conditional jump, if the jump is the last insn of the loop. This
> > prevents "gcc_assert (!JUMP_P (last))" from triggering.
> >
> > The NOP will never make it into the final assembly code because it is
> > removed during the cse1 pass through DCE for -O1, -O2, and -O3, and
> it's
> > not even emitted for -O0 and -Os because looping memcpy's are not
> > generated for those optimization levels, as can be seen in
> > mips_expand_block_move from mips.c:
> >
> >   if (INTVAL (length) <= MIPS_MAX_MOVE_BYTES_STRAIGHT)
> > {
> >   mips_block_move_straight (dest, src, INTVAL (length));
> >   return true;
> > }
> >   else if (optimize)
> > {
> >   mips_block_move_loop (dest, src, INTVAL (length),
> >
>   MIPS_MAX_MOVE_BYTES_PER_LOOP_ITER);
>

RE: [PATCH,testsuite] Skip gcc.dg/pic-2.c and gcc.dg/pie-2.c for MIPS.

2017-03-20 Thread Moore, Catherine



> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Wednesday, March 15, 2017 11:37 AM
> To: Moore, Catherine <catherine_mo...@mentor.com>
> Cc: Toma Tabacu <toma.tab...@imgtec.com>; gcc-
> patc...@gcc.gnu.org
> Subject: RE: [PATCH,testsuite] Skip gcc.dg/pic-2.c and gcc.dg/pie-2.c for
> MIPS.
> 
> Toma Tabacu <toma.tab...@imgtec.com> writes:
> > The gcc.dg/pic-2.c and gcc.dg/pie-2.c tests are failing for MIPS targets
> > because __PIC__ is always set to 1 for MIPS.
> >
> > This patch makes the testsuite skip those two tests for all MIPS
> > targets.
> >
> > Tested with mips-mti-elf and mips-mti-linux-gnu.
> >
> > Should I have fixed this in target-supports.exp instead ?
> > I was worried that doing so would complicate the fpic and pie effective
> > target checks too much.
> 
> I think the skip is OK here. I'd like to get Catherine's opinion on
> this though too. I don't think we should change the definition of __PIC__
> for -fPIC on MIPS as multi-got solves 'most' issues. If we start trying to
> figure out what __PIC__ should mean on MIPS then we will get into a big
> mess with -mxgot as that is arguably __PIC__==2 but I expect there will
> be  several differing opinions.
> 
I think the skip is the right way to go as well.   The patch is OK with me.
Catherine

RE: install.texi and mips-- (was: Target maintainers: doc/install.texi love and care)

2017-03-12 Thread Moore, Catherine



> -Original Message-
> From: Gerald Pfeifer [mailto:ger...@pfeifer.com]
> Sent: Sunday, March 12, 2017 7:38 AM
> To: gcc-patches@gcc.gnu.org; Moore, Catherine
> <catherine_mo...@mentor.com>; Matthew Fortune
> <matthew.fort...@imgtec.com>
> Subject: install.texi and mips-*-* (was: Target maintainers: doc/install.texi
> love and care)
> 
> On Sun, 12 Mar 2017, Gerald Pfeifer wrote:
> > References to dependencies on really, really old versions of
> > binutils (talking 10+ years here) which I think we can remove.
> > Let me follow-up with some of you with concrete suggestions
> > around that.
> 
> The mips-*-* currently has this:
> 
>   The assembler from GNU binutils 2.17 and earlier has a bug in the way
>   it sorts relocations for REL targets (o32, o64, EABI).  This can cause
>   bad code to be generated for simple C++ programs.  Also the linker
>   from GNU binutils versions prior to 2.17 has a bug which causes the
>   runtime linker stubs in very large programs to
>   be incorrectly generated.  GNU Binutils 2.18 and later (and snapshots
>   made after Nov. 9, 2006) should be free from both of these problems.
> 
> (Even that goes back more than 10 years.)
> 
> Okay to yank it?

Yes, thank you.  I will review the rest of the MIPS doc in install.texi this 
week.
Catherine

RE: [PATCH,testsuite] Skip gcc.dg/lto/pr60449_0.c for mips--elf* targets.

2017-03-02 Thread Moore, Catherine



> -Original Message-
> From: Toma Tabacu [mailto:toma.tab...@imgtec.com]
> Sent: Thursday, March 2, 2017 11:47 AM
> To: Rainer Orth <r...@cebitec.uni-bielefeld.de>
> Cc: Moore, Catherine <catherine_mo...@mentor.com>; gcc-
> patc...@gcc.gnu.org; Matthew Fortune
> <matthew.fort...@imgtec.com>
> Subject: RE: [PATCH,testsuite] Skip gcc.dg/lto/pr60449_0.c for mips*-*-
> elf* targets.
> 
> Hi,
> 
> > From: Rainer Orth
> > >
> > > gcc/testsuite/
> > >
> > >   * gcc.dg/lto/pr60449_0.c: Add dg-require-effective-target for
> > >   gettimeofday. Remove dg-skip-if for AVR.
> >
> > Two spaces after period.
> >
> 
> Fixed.
> 
> > >   * lib/target-supports.exp (check_effective_target_gettimeofday):
> New.
> >
> > Better say "New proc." or something like this.
> >
> 
> Fixed.
> 
> >
> > Thanks for your patience.
> >
> > Rainer
> 
> No problem.
> Thanks for the review.
> 
> Below is the version with the updated ChangeLog entries.
> 
> Catherine, Matthew, what do you think ?
> 

This patch fixes my original objection.  Thanks.

RE: [PATCH,testsuite] Skip gcc.dg/lto/pr60449_0.c for mips--elf* targets.

2017-02-28 Thread Moore, Catherine



> -Original Message-
> From: Toma Tabacu [mailto:toma.tab...@imgtec.com]
> Sent: Tuesday, February 28, 2017 9:32 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Matthew Fortune <matthew.fort...@imgtec.com>; Moore,
> Catherine <catherine_mo...@mentor.com>
> Subject: [PATCH,testsuite] Skip gcc.dg/lto/pr60449_0.c for mips*-*-elf*
> targets.
> 
> Hi,
> 
> The gcc.dg/lto/pr60449_0.c is failing for mips*-*-elf* targets because
> they do
> not support gettimeofday, which is used in this test case.
> 
> This patch changes the test so that it is skipped for mips*-*-elf* targets.
> 

Hi Toma, 
There are some MIPS ELF targets that do support gettimeofday.   Perhaps you 
could handle this with a dg_require_effective_target entry for gettimeofday.
Thanks,
Catherine

> 
> gcc/testsuite/
> 
>   * gcc.dg/lto/pr60449_0.c (dg-skip-if): Skip for mips*-*-elf*.
> 
> diff --git a/gcc/testsuite/gcc.dg/lto/pr60449_0.c
> b/gcc/testsuite/gcc.dg/lto/pr60449_0.c
> index 5b878a6..6f3eccb 100644
> --- a/gcc/testsuite/gcc.dg/lto/pr60449_0.c
> +++ b/gcc/testsuite/gcc.dg/lto/pr60449_0.c
> @@ -1,5 +1,5 @@
>  /* { dg-lto-do link } */
> -/* { dg-skip-if "Needs gettimeofday" { "avr-*-*" } } */
> +/* { dg-skip-if "Needs gettimeofday" { "avr-*-*" mips*-*-elf* } } */
> 
>  extern int printf (const char *__restrict __format, ...);
>  typedef long int __time_t;

RE: [PATCH,MIPS] Handle paired single test changes

2017-02-24 Thread Moore, Catherine



> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Matthew Fortune
> Sent: Thursday, February 23, 2017 5:21 PM
> To: Moore, Catherine <catherine_mo...@mentor.com>
> Cc: 'gcc-patches@gcc.gnu.org' (gcc-patches@gcc.gnu.org)  patc...@gcc.gnu.org>
> Subject: [PATCH,MIPS] Handle paired single test changes
> 
> Hi Catherine,
> 
> I missed a couple of testsuite changes that are needed to deal with the
> fallout of fixing the ABI issues for floating point vectors.  I had them
> in my tree but forgot to post.  The ABI change for V2SF i.e. paired
> single is a bug fix as the behaviour was unintended and violates the goal
> of having FP64 a compatible ABI extension for o32.  The probability of
> having code dependent on this corner case of the calling convention in
> the wild is exceptionally low so I see no significant risk still.
> 
> The tests for paired single just need a little encouragement to still
> produce the necessary instructions now that paired single is not returned
> in registers.
> 
> Does it look OK to you?
> 
> Thanks,
> Matthew
> 
> gcc/testsuite/
> 
>   * gcc.target/mips/mips-ps-type-2.c (move): Force generation
>   of mov.ps.
>   * gcc.target/mips/mips-ps-type.c (move): Likewise.
>   (cond_move1): Simplify condition to force generation of
>   mov[nz].ps.
>   (cond_move2): Likewise.

Hi Matthew -- Looks good to me.
Catherine

RE: [PATCH,MIPS] Document -mload-store-pairs

2017-02-24 Thread Moore, Catherine



> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Friday, February 24, 2017 8:58 AM
> To: Moore, Catherine <catherine_mo...@mentor.com>
> Cc: 'gcc-patches@gcc.gnu.org' (gcc-patches@gcc.gnu.org)  patc...@gcc.gnu.org>
> Subject: [PATCH,MIPS] Document -mload-store-pairs
> 
> Hi Catherine,
> 
> Can you review the description for -mload-store-pairs please?
> 
> Thanks,
> Matthew
> 
> gcc/
>   PR target/79473
>   * doc/invoke.texi: Document -mload-store-pairs.
> 
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 6e5fa56..f1fc449 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -879,6 +879,7 @@ Objective-C and Objective-C++ Dialects}.
>  -mexplicit-relocs  -mno-explicit-relocs @gol
>  -mcheck-zero-division  -mno-check-zero-division @gol
>  -mdivide-traps  -mdivide-breaks @gol
> +-mload-store-pairs  -mno-load-store-pairs @gol
>  -mmemcpy  -mno-memcpy  -mlong-calls  -mno-long-calls @gol
>  -mmad  -mno-mad  -mimadd  -mno-imadd  -mfused-madd  -mno-fused-
> madd  -nocpp @gol
>  -mfix-24k  -mno-fix-24k @gol
> @@ -19495,6 +19496,16 @@ overridden at configure time using
> @option{--with-divide=breaks}.
>  Divide-by-zero checks can be completely disabled using
>  @option{-mno-check-zero-division}.
> 
> +@item -mload-store-pairs
> +@itemx -mno-load-store-pairs
> +@opindex mload-store-pairs
> +@opindex mno-load-store-pairs
> +Enable (disable) an optimization that keeps consecutive load or store
> +instructions sequential to allow MIPS processors that perform load
> +and store bonding to optimize the access.  This option is enabled by
> +default but only takes effect when the selected architecture is known
> +to support bonding.
> +
>  @item -mmemcpy
>  @itemx -mno-memcpy
>  @opindex mmemcpy
> --
> 2.2.1

Hi Matthew -- How about this instead?

+@item -mload-store-pairs
+@itemx -mno-load-store-pairs
+@opindex mload-store-pairs
+@opindex mno-load-store-pairs
+Enable (disable) an optimization that pairs consecutive load or store
+instructions to enable load/store bonding.  This option is enabled by
+default but only takes effect when the selected architecture is known
+to support bonding.
+

RE: [PATCH, MIPS] Calling convention differs depending on the presence of MSA

2017-02-21 Thread Moore, Catherine



> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Tuesday, February 21, 2017 5:35 AM
> To: Sameera Deshpande <sameera.deshpa...@imgtec.com>; Moore,
> Catherine <catherine_mo...@mentor.com>
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH, MIPS] Calling convention differs depending on the
> presence of MSA
> 
> 
> As this is an ABI fix, just wait a day or so in case Catherine has
> any comment otherwise OK to commit.
> 
I have not  further comments on this patch.  Please commit.

RE: [PATCH][MIPS] MSA machine description fixes

2017-02-21 Thread Moore, Catherine

> The patch fixes some bugs as mentioned below.
> 
> 1. mips_gen_const_int_vector(): Change type for argument VAL from
> int to HOST_WIDE_INT to allow const vector of type doubleword. It in
> turn enables generation of BCLRI.d instead of AND.d for immediate
> const vector operand with only one bit clear.
> 
> 2. MSA dot product family instruction for .d format: Fix wrong MODE
> for vec_select in the second mult operand. It enables some
> optimizations like CSE fwprop etc.
> 
> 3. signed min/max immediate: Fix print operand code so as to print
> signed immediate instead of an unsigned one.
> 
> 4. MSA max/min absolute instruction family: Introduce mode iterator
> in if_then_else construct. It enables some optimizations like CSE
> fwprop etc.
> 
> Tests for all of them are also included in the patch.
> 
> Ok for trunk?
> 
> Changelog:
> 
> 2017-02-07  Prachi Godbole  
> 
> gcc/
>   * config/mips/mips-msa.md (msa_dotp__d,
> msa_dpadd__d,
>   msa_dpsub__d): Fix MODE for vec_select.
>   (msa_fmax_a_, msa_fmin_a_,
> msa_max_a_,
>   msa_min_a_): Introduce mode interator for
> if_then_else.
>   (smin3, smax3): Change operand print code
> from 'B' to 'E'.
>   * config/mips/mips.c (mips_gen_const_int_vector): Change
> type of last
>   argument.
>   * config/mips/mips-protos.h (mips_gen_const_int_vector):
> Likewise.
> 
Hi Prachi,

This part of the patch is fine, although I would like you to split it into 
three patches giving a separate commit for each bug fix.

> gcc/testsuite/
>   * gcc.target/mips/msa-1.c: New tests.

The testsuite patch should be split be split as well.  I have a couple of 
comments on the test itself.
> 
> 
> Index: gcc/testsuite/gcc.target/mips/msa-1.c
> ==
> =
> --- gcc/testsuite/gcc.target/mips/msa-1.c   (revision 0)
> +++ gcc/testsuite/gcc.target/mips/msa-1.c   (revision 0)
> @@ -0,0 +1,69 @@
> +/* { dg-do compile } */
> +/* { dg-options "-mno-mips16 -mfp64 -mhard-float -mmsa" } */
> +
> +typedef int v4i32 __attribute__ ((vector_size(16)));
> +typedef long long v2i64 __attribute__ ((vector_size(16)));
> +typedef float v4f32 __attribute__ ((vector_size(16)));
> +
> +/* Test MSA AND.d optimization: generate BCLRI.d instead, for
> immediate const
> +   vector operand with only one bit clear.  */
> +
> +void
> +and_d_msa (v2i64 *vx, v2i64 *vy)
> +{
> +  v2i64 and_vec = {0x7FFF, 0x7FFF};
> +  *vy = (*vx) & and_vec;
> +}

I know that compiler crashed for this test, but let's test for the generation 
of the BCLRI as well.

> +
> +/* Test MSA dot product family for CSE optimization.  */
> +
> +static v4i32 g = {0, 92, 93, 94};
> +static v4i32 h = {12, 24, 36, 48};
> +static v2i64 l = {84, 98};
> +
> +void
> +dotp_d_msa (v2i64 *c)
> +{
> +  l = __builtin_msa_dotp_s_d (g, h);
> +}
> +
> +void
> +dpadd_d_msa (v2i64 *c)
> +{
> +  *c = __builtin_msa_dpadd_s_d (l, g, h);
> +}
> +
> +void
> +dpsub_d_msa (v2i64 *c)
> +{
> +  *c = __builtin_msa_dpsub_s_d (l, g, h);
> +}

Likewise.  Can you test the assembly or one of the dumps for the optimization 
that you're looking for?

> +
> +/* Test MSA signed min/max immediate for correct assembly output.
> */
> +
> +void
> +min_s_msa (v4i32 *vx, v4i32 *vy)
> +{
> +  *vy = __builtin_msa_mini_s_w (*vx, -15);
> +}
> +/* { dg-final { scan-assembler "-15" } }  */
> +
> +void
> +max_s_msa (v4i32 *vx, v4i32 *vy)
> +{
> +  *vy = __builtin_msa_maxi_s_w (*vx, -15);
> +}
> +/* { dg-final { scan-assembler "-15" } }  */
> +
> +/* Test MSA min_a/max_a instructions for forward propagation
> optimization.  */
> +
> +#define FUNC(NAME, TYPE, RETTYPE) RETTYPE NAME##_a_msa (TYPE
> *vx, TYPE *vy) \
> +{ \
> +  TYPE dest = __builtin_msa_##NAME##_a_w (*vx, *vy); \
> +  return dest[0]; \
> +}
> +
> +FUNC(fmin, v4f32, float)
> +FUNC(fmax, v4f32, float)
> +FUNC(min, v4i32, int)
> +FUNC(max, v4i32, int)

This is OK.

Please repost the patches with the modifications.
Thanks,
Catherine

RE: [patch mips/gcc] add build-time and runtime options to disable or set madd.fmt type

2017-01-19 Thread Moore, Catherine



> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Thursday, January 19, 2017 5:30 PM
> To: Moore, Catherine <catherine_mo...@mentor.com>
> Cc: 'Aurelien Jarno' <aurel...@aurel32.net>; 'Richard Sandiford'
> <rdsandif...@googlemail.com>; Loosemore, Sandra
> <sandra_loosem...@mentor.com>; Yunqiang Su
> <yunqiang...@imgtec.com>; 'gcc-patches' <gcc-patches@gcc.gnu.org>
> Subject: RE: [patch mips/gcc] add build-time and runtime options to
> disable or set madd.fmt type
> 
> Matthew Fortune <matthew.fort...@imgtec.com> writes:
> > I've rewritten/simplified this patch as it provides far too much
> control
> > to end users who will undoubtedly shoot themselves in the foot so to
> > speak. The option I intend to support is simply --with-madd4 --
> without-madd4
> > and -mmadd4 -mno-madd4. This is a simple enable/disable on top of
> > architecture checks to use/not use the madd4 family of instructions.
> >
> > We have to keep each of these unusual features simple so that we
> can somehow
> > reason about them in the future.
> >
> 
> Here is the tested patch.  Configure time default set/not set tested and
> testsuite
> fixes in place to deal with the fallout from running with the madd4
> instructions
> disabled.  Tests done with an o32 config on mips64el-linux-gnu.  If
> there is any
> other fallout from other test configurations I'll catch those as I try to
> get the
> rest of the testsuite issues resolved before release.
> 
> Catherine, any issues to raise on this new option?

I committed this patch after fixing a couple of typos in the documentation and 
ChangeLog entry.
No other objections.
Catherine

> 
> Thanks,
> Matthew
> 
> gcc/
> 
>   * config.gcc (supported_defaults): Add madd4.
>   (with_madd4): Add validation.
>   (all_defaults): Add madd4.
>   * config/mips/mips.opt (mmadd4): New option.
>   * gcc/config/mips/mips.h (OPTION_DEFAULT_SPECS): Add a
> default for
>   mmadd4.
>   (TARGET_CPU_CPP_BUILTINS): Add builtin_define for
>   __mips_no_madd4.
>   (ISA_HAS_UNFUSED_MADD4): Gate with mips_madd4.
>   (ISA_HAS_FUSED_MADD4): Likewise.
>   * gcc/doc/invoke.texi (-mmadd4): Document the new option.
>   * doc/install.texi (--with-madd4): Document the new option.
> 
> gcc/testsuite/
> 
>   * gcc.target/mips/madd4-1.c: New file.
>   * gcc.target/mips/madd4-2.c: Likewise.
>   * gcc.target/mips/mips.exp (mips_option_groups): Add ghost
> option
>   HAS_MADD4.
>   (mips_option_groups): Add -m[no-]madd4.
>   (mips-dg-init): Detect default -mno-madd4.
>   (mips-dg-options): Handle HAS_MADD4 arch
> upgrade/downgrade.
>   * gcc.target/mips/mips-ps-type.c: Add -mmadd4 test option.
>   * gcc.target/mips/mips-ps-type-2.c: Likewise.
>   * gcc.target/mips/nmadd-1.c: Likewise.
>   * gcc.target/mips/nmadd-2.c: Likewise.
>   * gcc.target/mips/nmadd-3.c: Likewise.
> ---
>  gcc/ChangeLog  | 16 
>  gcc/config.gcc | 19 +--
>  gcc/config/mips/mips.h | 12 +---
>  gcc/config/mips/mips.opt   |  4 
>  gcc/doc/install.texi   | 14 ++
>  gcc/doc/invoke.texi|  8 +++-
>  gcc/testsuite/ChangeLog| 15 +++
>  gcc/testsuite/gcc.target/mips/madd4-1.c| 14 ++
>  gcc/testsuite/gcc.target/mips/madd4-2.c| 14 ++
>  gcc/testsuite/gcc.target/mips/mips-ps-type-2.c |  2 +-
>  gcc/testsuite/gcc.target/mips/mips-ps-type.c   |  2 +-
>  gcc/testsuite/gcc.target/mips/mips.exp | 12 +++-
>  gcc/testsuite/gcc.target/mips/nmadd-1.c|  2 +-
>  gcc/testsuite/gcc.target/mips/nmadd-2.c|  2 +-
>  gcc/testsuite/gcc.target/mips/nmadd-3.c|  2 +-
>  15 files changed, 126 insertions(+), 12 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/mips/madd4-1.c
>  create mode 100644 gcc/testsuite/gcc.target/mips/madd4-2.c
> 
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index e53f9e1..7496071 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,19 @@
> +2017-01-19  Matthew Fortune  <matthew.fort...@imgtec.com>
> + Yunqiang Su  <yunqiang...@imgtec.com>
> +
> + * config.gcc (supported_defaults): Add madd4.
> + (with_madd4): Add validation.
> + (all_defaults): Add madd4.
> + * config/mips/mips.opt (mmadd4): New option.
> + * gcc/config/mips/mips.h (OPTION_DEFAULT_SPECS): Add a
&

RE: [PATCH, MIPS] Target flag and build option to disable indexed memory OPs.

2017-01-17 Thread Moore, Catherine



> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Tuesday, January 17, 2017 4:35 AM
> To: Moore, Catherine <catherine_mo...@mentor.com>; Doug
> Gilmore <doug.gilm...@imgtec.com>; gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH, MIPS] Target flag and build option to disable
> indexed memory OPs.
> 
> Moore, Catherine <catherine_mo...@mentor.com> writes:
> > > -Original Message-
> > > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > > ow...@gcc.gnu.org] On Behalf Of Matthew Fortune
> > > Sent: Monday, January 16, 2017 11:25 AM
> > > To: Doug Gilmore <doug.gilm...@imgtec.com>; gcc-
> > > patc...@gcc.gnu.org
> > > Cc: Moore, Catherine <catherine_mo...@mentor.com>
> > > Subject: RE: [PATCH, MIPS] Target flag and build option to disable
> > > indexed memory OPs.
> > >
> > > Doug Gilmore <doug.gilm...@imgtec.com>
> > > > I recently bisected PR78176 to problems introduced with r21650.
> > > >
> > > > Given the short time until the release, we would like to provide a
> > > > target flag and build option to avoid the bug until we are able to
> > > > resolve the problem with the commit.  Note that as Matthew
> Fortune
> > > has
> > > > mentioned in the PR:
> > > >
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176#c5
> > > >
> > > > the problem could also be addressed by updates to the Linux
> kernel
> > > since
> > > > the problem is only exposed by running MIPS 32-bit binaries on
> 64-
> > > bit
> > > > kernels.
> > > >
> > > > Bootstrapped on X86_64, regression tested on X86_64 and MIPS.
> > > >
> > > > OK to commit?
> > >
> > > Given this is a generic reference to indexed load/store and the
> issue
> > > could
> > > affect any indexed operation then I think it needs to include all of
> the
> > > following as well:
> > >
> > > /* ISA has lwxs instruction (load w/scaled index address.  */
> > > #define ISA_HAS_LWXS((TARGET_SMARTMIPS ||
> > > TARGET_MICROMIPS) \
> > >  && !TARGET_MIPS16)
> > >
> > > /* ISA has lbx, lbux, lhx, lhx, lhux, lwx, lwux, or ldx instruction. */
> > > #define ISA_HAS_LBX (TARGET_OCTEON2)
> > > #define ISA_HAS_LBUX(ISA_HAS_DSP || TARGET_OCTEON2)
> > > #define ISA_HAS_LHX (ISA_HAS_DSP || TARGET_OCTEON2)
> > > #define ISA_HAS_LHUX(TARGET_OCTEON2)
> > > #define ISA_HAS_LWX (ISA_HAS_DSP || TARGET_OCTEON2)
> > > #define ISA_HAS_LWUX(TARGET_OCTEON2 &&
> TARGET_64BIT)
> > > #define ISA_HAS_LDX ((ISA_HAS_DSP || TARGET_OCTEON2)
> \
> > >  && TARGET_64BIT)
> > >
> > > The DSP LBUX/LHX/LWX/LDX intrinsics will also need a new AVAIL
> > > predicate
> > > to disable them. The snag is that some DSP code will fail to compile
> if it
> > > uses the DSP load intrinsics directly.
> > >
> > > I see no way of avoiding that. Therefore, distributions that use
> > > --without-indexed-load-store will have to cope with some potential
> > > DSP
> > > fallout if they enable DSP at all.
> > >
> > > @Catherine: I'd like your input here if possible as I advocated this
> > > approach, comments on option names welcome too.  I quite like
> the
> > > verbose
> > > name.
> >
> > Okay, based on my reading of the comments in the bug report, you
> are proposing this option
> > as a workaround to a kernel deficiency.  I don't see any agreement
> that this is actually a
> > compiler bug.
> > Do we really need to include the DSP instrinsics as well?   Do you
> think that many
> > distributions actually enable DSP?
> >
> > The option name itself is acceptable to me.  I'd like to see
> documentation that explains
> > when this problem is exposed.  I'd like to limit the fix to LWXS and I'd
> like to see the
> > testcase from the bug report added to the testsuite.
> > I also agree that the preprocessor macro is a good idea (even if we
> decide to forgo the
> > DSP portion of the patch).
> 
> Thanks for the comments.
> 
> Having thought further I agree we can safely ignore DSP indexed load
> and micromips LWXS on
> the basis that DSP code will not run on a MIPS64 processor anyway (at
> least none that I
> know of) so the issue cannot occur and similarly for microMIPS, there
> are no 64-bit cores.
> 
> Restricting to just LWXC1/SWXC1/LDXC1/SDXC1 is therefore fine but
> we should reflect
> that in option names then.
> 
> --with-lxc1-sxc1 --without-lxc1-sxc1
> -mlxc1-sxc1
> 
> These names reflect the internal macro that controls availability of
> these instructions.
> 
> Macro name: __mips_no_lxc1_sxc1
> Defined when !ISA_HAS_LXC1_SXC1 so would be present even when
> targeting a core that
> doesn't have the instructions anyway.
> 
> Any refinements to this Catherine?
> 
No.  This plan looks good.

RE: [PATCH, MIPS] Target flag and build option to disable indexed memory OPs.

2017-01-16 Thread Moore, Catherine



> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Matthew Fortune
> Sent: Monday, January 16, 2017 11:25 AM
> To: Doug Gilmore <doug.gilm...@imgtec.com>; gcc-
> patc...@gcc.gnu.org
> Cc: Moore, Catherine <catherine_mo...@mentor.com>
> Subject: RE: [PATCH, MIPS] Target flag and build option to disable
> indexed memory OPs.
> 
> Doug Gilmore <doug.gilm...@imgtec.com>
> > I recently bisected PR78176 to problems introduced with r21650.
> >
> > Given the short time until the release, we would like to provide a
> > target flag and build option to avoid the bug until we are able to
> > resolve the problem with the commit.  Note that as Matthew Fortune
> has
> > mentioned in the PR:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176#c5
> >
> > the problem could also be addressed by updates to the Linux kernel
> since
> > the problem is only exposed by running MIPS 32-bit binaries on 64-
> bit
> > kernels.
> >
> > Bootstrapped on X86_64, regression tested on X86_64 and MIPS.
> >
> > OK to commit?
> 
> Given this is a generic reference to indexed load/store and the issue
> could
> affect any indexed operation then I think it needs to include all of the
> following as well:
> 
> /* ISA has lwxs instruction (load w/scaled index address.  */
> #define ISA_HAS_LWXS((TARGET_SMARTMIPS ||
> TARGET_MICROMIPS) \
>  && !TARGET_MIPS16)
> 
> /* ISA has lbx, lbux, lhx, lhx, lhux, lwx, lwux, or ldx instruction. */
> #define ISA_HAS_LBX (TARGET_OCTEON2)
> #define ISA_HAS_LBUX(ISA_HAS_DSP || TARGET_OCTEON2)
> #define ISA_HAS_LHX (ISA_HAS_DSP || TARGET_OCTEON2)
> #define ISA_HAS_LHUX(TARGET_OCTEON2)
> #define ISA_HAS_LWX (ISA_HAS_DSP || TARGET_OCTEON2)
> #define ISA_HAS_LWUX(TARGET_OCTEON2 && TARGET_64BIT)
> #define ISA_HAS_LDX ((ISA_HAS_DSP || TARGET_OCTEON2) \
>  && TARGET_64BIT)
> 
> The DSP LBUX/LHX/LWX/LDX intrinsics will also need a new AVAIL
> predicate
> to disable them. The snag is that some DSP code will fail to compile if it
> uses the DSP load intrinsics directly.
> 
> I see no way of avoiding that. Therefore, distributions that use
> --without-indexed-load-store will have to cope with some potential
> DSP
> fallout if they enable DSP at all.
> 
> @Catherine: I'd like your input here if possible as I advocated this
> approach, comments on option names welcome too.  I quite like the
> verbose
> name.

Okay, based on my reading of the comments in the bug report, you are proposing 
this option as a workaround to a kernel deficiency.  I don't see any agreement 
that this is actually a compiler bug.
Do we really need to include the DSP instrinsics as well?   Do you think that 
many distributions actually enable DSP?  

The option name itself is acceptable to me.  I'd like to see documentation that 
explains when this problem is exposed.  I'd like to limit the fix to LWXS and 
I'd like to see the testcase from the bug report added to the testsuite.
I also agree that the preprocessor macro is a good idea (even if we decide to 
forgo the DSP portion of the patch).

Catherine

> 
> @Doug: Have you tried running the testsuite with the configure option
> --without-indexed-load-store? There may be tests that need adjusting
> where they
> test indexed load/store. We probably need a pre-processor macro
> to detect if the option is enabled/disabled so that DSP code can be
> predicated
> on indexed load being available.
> 
> Thanks,
> Matthew

RE: [PATCH, testsuite] MIPS: Cleanup the forcing of assembly output in error tests.

2016-12-22 Thread Moore, Catherine



> -Original Message-
> From: Toma Tabacu [mailto:toma.tab...@imgtec.com]
> Sent: Wednesday, December 14, 2016 9:56 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Matthew Fortune <matthew.fort...@imgtec.com>; Moore,
> Catherine <catherine_mo...@mentor.com>
> Subject: [PATCH, testsuite] MIPS: Cleanup the forcing of assembly
> output in error tests.
> 
> Hi,
> 
> Some error tests were forcing assembly output incorrectly, and none
> of them had
> an explanation for why they were using -ffat-lto-objects.
> 
> This patch removes dg-skip-if's for -fno-fat-lto-objects and
> adds -ffat-lto-objects to the test options instead.
> It also adds an explanation for the purpose of -ffat-lto-objects in each
> test.
> 
> Tested with mips-mti-elf.
> 
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/mips/oddspreg-2.c (dg-options): Remove dg-skip-if
> for
>   -fno-fat-lto-objects and add the -ffat-lto-objects option, along
> with
>   an explanation for its purpose.
>   * gcc.target/mips/oddspreg-3.c (dg-options): Likewise.
>   * gcc.target/mips/oddspreg-6.c (dg-options): Likewise.
>   * gcc.target/mips/no-dsp-1.c: Add an explanation for the
> purpose of
>   -ffat-lto-objects.
>   * gcc.target/mips/pr54240.c: Likewise.
>   * gcc.target/mips/r10k-cache-barrier-14.c: Likewise.
>   * gcc.target/mips/soft-float-1.c: Likewise.
> 

This is OK.

RE: [PATCH, testsuite] MIPS: Relax instruction order check in msa-builtins.c.

2016-12-19 Thread Moore, Catherine



> -Original Message-
> From: Toma Tabacu [mailto:toma.tab...@imgtec.com]
> Sent: Thursday, December 15, 2016 9:51 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Matthew Fortune <matthew.fort...@imgtec.com>; Moore,
> Catherine <catherine_mo...@mentor.com>
> Subject: [PATCH, testsuite] MIPS: Relax instruction order check in msa-
> builtins.c.
> 
> Hi,
> 
> The 32-bit insert.d case in msa-builtins.c is failing with O2 and Os
> because
> the order of the emitted instructions is slightly different compared to
> the
> other optimization levels.
> 
> This patch tweaks the regular expression for 32-bit insert.d to accept
> the
> alternate instruction order.
> 
> Tested with mips-mti-elf.
> 
> Regards,
> Toma
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/mips/msa-builtins.c (dg-final): Tweak regex for the
> 32-bit
>   insert.d case.

Please change to:
* gcc.target/mips-msa-builtins.c (msa_insert_d): Tweak expected output.

Okay with that change.
Thanks,
Catherine

> 
> diff --git a/gcc/testsuite/gcc.target/mips/msa-builtins.c
> b/gcc/testsuite/gcc.target/mips/msa-builtins.c
> index 6db3d66..a679f06 100644
> --- a/gcc/testsuite/gcc.target/mips/msa-builtins.c
> +++ b/gcc/testsuite/gcc.target/mips/msa-builtins.c
> @@ -481,7 +481,7 @@
>  /* { dg-final { scan-assembler-times
> "msa_insert_h:.*insert\\.h.*msa_insert_h" 1 } } */
>  /* { dg-final { scan-assembler-times
> "msa_insert_w:.*insert\\.w.*msa_insert_w" 1 } } */
>  /* { dg-final { scan-assembler-times
> "msa_insert_d:.*insert\\.d.*msa_insert_d" 1 { target mips64 } } } */
> -/* { dg-final { scan-assembler-times
> "msa_insert_d:.*sra.*insert.w.*insert.w.*msa_insert_d" 1 { target {!
> mips64 } } } } */
> +/* { dg-final { scan-assembler
> "msa_insert_d:.*(sra.*insert.w.*insert.w|insert.w.*sra.*insert.w).*ms
> a_insert_d" { target {! mips64 } } } } */
>  /* { dg-final { scan-assembler-times
> "msa_insve_b:.*insve\\.b.*msa_insve_b" 1 } } */
>  /* { dg-final { scan-assembler-times
> "msa_insve_h:.*insve\\.h.*msa_insve_h" 1 } } */
>  /* { dg-final { scan-assembler-times
> "msa_insve_w:.*insve\\.w.*msa_insve_w" 1 } } */

RE: [PATCH, testsuite] MIPS: Add isa>=2 option to interrupt_handler-bug-1.c.

2016-11-21 Thread Moore, Catherine



> -Original Message-
> From: Toma Tabacu [mailto:toma.tab...@imgtec.com]
> Sent: Monday, November 21, 2016 8:53 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Matthew Fortune <matthew.fort...@imgtec.com>; Moore,
> Catherine <catherine_mo...@mentor.com>
> Subject: [PATCH, testsuite] MIPS: Add isa>=2 option to
> interrupt_handler-bug-1.c.
> 
> Hi,
> 
> Currently, the interrupt_handler-bug-1.c test will fail on pre-R2 targets
> because the "interrupt" function attribute requires at least an R2 target
> and
> the test does not enforce this requirement.
> 
> This patch fixes this by adding the isa_rev>=2 option to the test's dg-
> options.
> 
> Tested with mips-mti-elf.
> 
> Regards,
> Toma Tabacu
> 
> gcc/testsuite/ChangeLog:
> 
> 2016-11-21  Toma Tabacu  <toma.tab...@imgtec.com>
> 
>   * gcc.target/mips/interrupt_handler-bug-1.c (dg-options): Add
>   isa_rev>=2.
> 

Yes, this is okay to commit.

RE: [PATCH,testsuite] MIPS: Downgrade from R6 to R5 to prevent redundant testing of branch-cost-1.c.

2016-11-17 Thread Moore, Catherine

> gcc/testsuite/ChangeLog:
> 
> 2016-11-15  Toma Tabacu  
> 
>   * gcc.target/mips/branch-cost-1.c (dg-options): Use
> (HAS_MOVN) instead
>   of isa>=4, in order to downgrade to R5.
> 
> diff --git a/gcc/testsuite/gcc.target/mips/branch-cost-1.c
> b/gcc/testsuite/gcc.target/mips/branch-cost-1.c
> index 61c3029..7f7ebbe 100644
> --- a/gcc/testsuite/gcc.target/mips/branch-cost-1.c
> +++ b/gcc/testsuite/gcc.target/mips/branch-cost-1.c
> @@ -1,4 +1,4 @@
> -/* { dg-options "-mbranch-cost=1 isa>=4" } */
> +/* { dg-options "-mbranch-cost=1 (HAS_MOVN)" } */
>  /* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
>  NOMIPS16 int
>  foo (int x, int y, int z, int k)

I committed this patch for you.  Have you requested  write access to the 
repository?
Catherine

RE: [PATCH] MIPS: If a test in the MIPS testsuite requires standard library support check the sysroot supports the required test options.

2016-11-17 Thread Moore, Catherine



> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Matthew Fortune
> Sent: Thursday, November 17, 2016 8:47 AM
> To: Toma Tabacu <toma.tab...@imgtec.com>; Andrew Bennett
> <andrew.benn...@imgtec.com>; Moore, Catherine
> <catherine_mo...@mentor.com>; 'gcc-patches@gcc.gnu.org'  patc...@gcc.gnu.org>
> Subject: RE: [PATCH] MIPS: If a test in the MIPS testsuite requires
> standard library support check the sysroot supports the required test
> options.
> 
> Toma Tabacu <toma.tab...@imgtec.com> writes:
> > Hi,
> >
> > The patch below is a rebased version of Andrew's patch plus a few
> more changes
> > to test options.
> >
> > I have tested Andrew's patch by passing -msoft-float to the testsuite
> without
> > having a soft-float library available, and saw that the inline-memcpy-
> {1,2,3,4,5}.c
> > and memcpy-1.c tests were also failing to find standard library
> headers.
> > In the version below, I have added (REQUIRES_STDLIB) to them as
> well.
> >
> > However, I believe that the memcpy-1.c test was removed from the
> first version
> > of Andrew's patch in response to Matthew's comments, but I don't
> think it
> > should be.
> >
> > Tested with mips-img-linux-gnu and mips-mti-linux-gnu.
> 
> This looks OK to me but I then again I helped with the design for this.
> 
> I'd like to give Catherine a chance to take a look though as the feature
> is unusual.
> 
> One comment below.
> 
> > diff --git a/gcc/testsuite/gcc.target/mips/mips.exp
> > b/gcc/testsuite/gcc.target/mips/mips.exp
> > index e22d782..ccd4ecb 100644
> > --- a/gcc/testsuite/gcc.target/mips/mips.exp
> > +++ b/gcc/testsuite/gcc.target/mips/mips.exp
> > @@ -1420,6 +1426,22 @@ proc mips-dg-options { args } {
> > }
> >  }
> >
> > +# If the test is marked as requiring standard libraries check
> > +# that the sysroot has support for the current set of test options.
> > +if { [mips_have_test_option_p options "REQUIRES_STDLIB"] } {
> > +   mips_push_test_options saved_options $extra_tool_flags
> > +   set output [mips_preprocess "" {
> > + #include 
> > +   } 1]
> > +   mips_pop_test_options saved_options
> > +
> > +   # If the preprocessing of the stdlib.h file produced errors mark
> > +   # the test as unsupported.
> > +   if { ![string equal $output ""] } {
> > +   set do_what [lreplace $do_what 1 1 "N"]
> 
> We should describe what we expect the format of do_what to be at
> the time
> of writing in case it ever changes. i.e. a comment to say what the
> second
> character means and therefore make it clear that setting it to 'n' makes
> the test unsupported.
> 

This patch looks okay to me after updating the comment as Matthew suggested.

RE: RFA: PATCH to gengtype to avoid putting tree_node support in front end objects

2016-11-16 Thread Moore, Catherine



> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jakub Jelinek
> Sent: Thursday, November 10, 2016 7:53 AM
> To: Jason Merrill 
> Cc: gcc-patches List 
> Subject: Re: RFA: PATCH to gengtype to avoid putting tree_node
> support in front end objects
> 
> On Thu, Oct 27, 2016 at 09:36:09AM -0400, Jason Merrill wrote:
> > Currently, the way gengtype works it scans the list of source files
> > with front end files at the end, and pushes data structures onto a
> > stack.  It then processes the stack in LIFO order, so that data
> > structures from front ends are handled first.  As a result, if a GTY
> > data structure in a front end depends on tree_node, gengtype
> happily
> > puts gt_ggc_mx(tree_node*&) in a front end file, leading to link
> > errors on all other front ends.
> >
> > This patch avoids this problem by appending to the list of data
> > structures so that they are processed in FIFO order, and so
> tree_node
> > gets handled in gtype-desc.o.
> >
> > Tested x86_64-pc-linux-gnu, OK for trunk?
> 
> > commit 487a1c95c0d3169b2041942ff4f8d71c9ff689eb
> > Author: Jason Merrill 
> > Date:   Wed Oct 26 23:12:23 2016 -0400
> >
> > * gengtype.c (new_structure): Append to structures list.
> >
> > (find_structure): Likewise.
> 
> Please remove the blank line in the ChangeLog.
> 
> When looking at the differences it creates, it is hard, because
> all the generated files have all the functions emitted in reverse order
> now
> from what it used to be, so I only looked at files where the size
> changed,
> and that is beyond gtype.state only in my case gt-tree-phinodes.h
> which lost
> void
> gt_ggc_mx (struct gimple *& x)
> {
>   if (x)
> gt_ggc_mx_gimple ((void *) x);
> }
> and
> void
> gt_pch_nx (struct gimple *& x)
> {
>   if (x)
> gt_pch_nx_gimple ((void *) x);
> }
> and gtype-desc.c which didn't contain those but now it does (for
> gtype-desc.c it is hard to find out due to the reordering what else
> has changed, but as gt-tree-phinodes.h shrunk by 170 characters and
> gtype-desc.c grew by 170 characters, I'd think it is all that changed).
> I believe those routines belong to gtype-desc.c, that is where similar
> ones for tree_node, etc. are, tree-phinodes.h certainly isn't the header
> that defines gimple.
> 
> So I think this patch is ok for trunk.  Thanks.
> 

Hi -- This patch caused breakage for the MIPS port while compiling 
gcc/config/mips.c:

In file included from 
/scratch/cmoore/mips-sde-elf-upstream/src/gcc-trunk-6/gcc/hash-table.h:561:0,
 from 
/scratch/cmoore/mips-sde-elf-upstream/src/gcc-trunk-6/gcc/coretypes.h:351,
 from 
/scratch/cmoore/mips-sde-elf-upstream/src/gcc-trunk-6/gcc/config/mips/mips.c:26:
/scratch/cmoore/mips-sde-elf-upstream/src/gcc-trunk-6/gcc/hash-map.h: In 
instantiation of 'static void hash_map< , 
,  
>::hash_entry::ggc_mx(hash_map< , 
,  >::hash_entry&) [with KeyId 
= nofree_string_hash; Value = rtx_def*; Traits = 
simple_hashmap_traits]':
/scratch/cmoore/mips-sde-elf-upstream/src/gcc-trunk-6/gcc/hash-table.h:1029:17: 
  required from 'void gt_ggc_mx(hash_table*) [with E = 
hash_map::hash_entry]'
/scratch/cmoore/mips-sde-elf-upstream/src/gcc-trunk-6/gcc/hash-map.h:251:13:   
required from 'void gt_ggc_mx(hash_map*) [with K = nofree_string_hash; 
V = rtx_def*; H = 
simple_hashmap_traits]'
./gt-mips.h:38:19:   required from here
/scratch/cmoore/mips-sde-elf-upstream/src/gcc-trunk-6/gcc/hash-map.h:62:12: 
error: no matching function for call to 'gt_ggc_mx(rtx_def*&)'
  gt_ggc_mx (e.m_value);
^
... etc

I configured with --target=mips-sde-elf, but I do have some local multilib 
definitions for that target.  This ought to reproduce with mti-elf as well.
Will you please fix or revert?

Thanks,
Catherine

RE: [PATCH,testsuite] MIPS: Upgrade to MIPS IV if using (HAS_MOVN) with MIPS III.

2016-11-09 Thread Moore, Catherine



> -Original Message-
> From: Toma Tabacu [mailto:toma.tab...@imgtec.com]
> Sent: Wednesday, November 9, 2016 12:19 PM
> Subject: RE: [PATCH,testsuite] MIPS: Upgrade to MIPS IV if using (HAS_MOVN) 
> with MIPS III.
> 
> No, I don't have write access.
> I would be grateful if you could commit the patch for me, if you think it
> would be OK with Matthew.
> To be clear, I am not in a rush to get this committed.

You're all set now.  I committed this:  revision 242021.

Catherine

> gcc/testsuite/ChangeLog:
> 
> 2016-11-09  Toma Tabacu  
> 
>   * gcc.target/mips/mips.exp (mips-dg-options): Upgrade to MIPS IV if
>   using (HAS_MOVN) with MIPS III.
>

RE: [PATCH,testsuite] MIPS: Upgrade to MIPS IV if using (HAS_MOVN) with MIPS III.

2016-11-08 Thread Moore, Catherine



> -Original Message-
> From: Toma Tabacu [mailto:toma.tab...@imgtec.com]
> Sent: Monday, November 7, 2016 11:21 AM
> gcc/testsuite/ChangeLog:
> 
> 2016-11-07  Toma Tabacu  
> 
>   * gcc.target/mips/mips.exp (mips-dg-options): Upgrade to MIPS IV if 
> using
>   (HAS_MOVN) with MIPS III.
> 
> diff --git a/gcc/testsuite/gcc.target/mips/mips.exp
> b/gcc/testsuite/gcc.target/mips/mips.exp
> index 39f44ff..e22d782 100644
> --- a/gcc/testsuite/gcc.target/mips/mips.exp
> +++ b/gcc/testsuite/gcc.target/mips/mips.exp
> @@ -1129,7 +1129,7 @@ proc mips-dg-options { args } {
>  # We need MIPS IV or higher for:
>   #
>   #
> - } elseif { $isa < 3
> + } elseif { $isa < 4
>  && [mips_have_test_option_p options "HAS_MOVN"] }
> {
>   mips_make_test_option options "-mips4"
>  # We need MIPS III or higher for:

Hi Toma,

The patch itself is OK, but the ChangeLog entry line length is greater than 80.

Do you have write access to the repository?  Please let me know if you would 
like me to commit this for you?

Thanks,
Catherine

RE: [PATCH,testsuite] MIPS: Downgrade R6 to R5 if tests need branch-likely instructions.

2016-11-03 Thread Moore, Catherine



> -Original Message-
> From: Toma Tabacu [mailto:toma.tab...@imgtec.com]
> Sent: Thursday, November 3, 2016 6:58 AM
> Subject: [PATCH,testsuite] MIPS: Downgrade R6 to R5 if tests need
> branch-likely instructions.
> 
> 
> gcc/testsuite/
> * gcc.target/mips/mips.exp: Add check for -mbranch-likely in
> condition for R5 downgrade.
> 

This patch is OK.
Catherine

[Patch][MIPS} [Committed] Fix gcc.dg/pch.exp failures for microMIPS multilibs

2016-10-14 Thread Moore, Catherine

I've committed this patch to fix failures in  g++.dg/pch.exp and gcc.dg/pch.exp 
tests when compiling with -mmicromips.  Invalid data was being read from the 
precompiled-header causing a segfault while trying to switch compression 
context.
This patch fixes that segfault by initializing micromips_globals to zero prior 
to writing the PCH file.  

Thanks,
Catherine

2016-10-13  Catherine Moore  

* gcc/config/mips/mips.c (mips_prepare_pch_save): Initialize
micromips_globals to zero.

diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 43174b4..ebec68e 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -20856,28 +20856,30 @@ mips_shift_truncation_mask (machine_mode mode)
 static void
 mips_prepare_pch_save (void)
 {
-  /* We are called in a context where the current MIPS16 vs. non-MIPS16
- setting should be irrelevant.  The question then is: which setting
- makes most sense at load time?
+  /* We are called in a context where the current compression vs.
+ non-compression setting should be irrelevant.  The question then is:
+ which setting makes most sense at load time?

- The PCH is loaded before the first token is read.  We should never
- have switched into MIPS16 mode by that point, and thus should not
- have populated mips16_globals.  Nor can we load the entire contents
- of mips16_globals from the PCH file, because mips16_globals contains
- a combination of GGC and non-GGC data.
+ The PCH is loaded before the first token is read.  We should never have
+ switched into a compression mode by that point, and thus should not have
+ populated mips16_globals or micromips_globals.  Nor can we load the
+ entire contents of mips16_globals or micromips_globals from the PCH file,
+ because they contain a combination of GGC and non-GGC data.

  There is therefore no point in trying save the GGC part of
- mips16_globals to the PCH file, or to preserve MIPS16ness across
- the PCH save and load.  The loading compiler would not have access
- to the non-GGC parts of mips16_globals (either from the PCH file,
- or from a copy that the loading compiler generated itself) and would
- have to call target_reinit anyway.
-
- It therefore seems best to switch back to non-MIPS16 mode at
- save time, and to ensure that mips16_globals remains null after
- a PCH load.  */
+ mips16_globals/micromips_globals to the PCH file, or to preserve a
+ compression setting across the PCH save and load.  The loading compiler
+ would not have access to the non-GGC parts of mips16_globals or
+ micromips_globals (either from the PCH file, or from a copy that the
+ loading compiler generated itself) and would have to call target_reinit
+ anyway.
+
+ It therefore seems best to switch back to non-MIPS16 mode and
+ non-microMIPS mode to save time, and to ensure that mips16_globals and
+ micromips_globals remain null after a PCH load.  */
   mips_set_compression_mode (0);
   mips16_globals = 0;
+  micromips_globals = 0;
 }
 ^L
 /* Generate or test for an insn that supports a constant permutation.  */

[MIPS, committed] microMIPS testsuite cleanup

2016-05-04 Thread Moore, Catherine


2016-05-04  Kwok Cheung Yeung  

* gcc.target/mips/mips16-attributes.c: Skip if -mmicromips
flag is present.

Index: gcc.target/mips/mips16-attributes.c
===
--- gcc.target/mips/mips16-attributes.c (revision 235880)
+++ gcc.target/mips/mips16-attributes.c (working copy)
@@ -3,6 +3,7 @@
function.  */
 /* { dg-do run } */
 /* { dg-options "(-mips16)" } */
+/* { dg-skip-if "" { *-*-* } { "-mmicromips" } { "" } } */

 #include

RE: [Patch, MIPS] Patch for PR 68400, a mips16 bug

2016-01-28 Thread Moore, Catherine



> -Original Message-
> From: Steve Ellcey [mailto:sell...@imgtec.com]
> Sent: Tuesday, January 26, 2016 3:43 PM
> To: gcc-patches@gcc.gnu.org
> Cc: matthew.fort...@imgtec.com; Moore, Catherine
> Subject: [Patch, MIPS] Patch for PR 68400, a mips16 bug
> 
> Here is a patch for PR6400.  The problem is that and_operands_ok was
> checking one operand to see if it was a memory_operand but MIPS16
> addressing is more restrictive than what the general memory_operand
> allows.  The fix was to call mips_classify_address if TARGET_MIPS16 is set
> because it will do a more complete mips16 addressing check and reject
> operands that do not meet the more restrictive requirements.
> 
> I ran the GCC testsuite with no regressions and have included a test case as
> part of this patch.
> 
> OK to checkin?
> 
> Steve Ellcey
> sell...@imgtec.com
> 
> 
> 2016-01-26  Steve Ellcey  <sell...@imgtec.com>
> 
>   PR target/68400
>   * config/mips/mips.c (and_operands_ok): Add MIPS16 check.
> 
> 
> 
This is OK.
Thanks, Catherine

RE: [PATCH] MIPS: Prevent the p5600-bonding.c test from being run for the n32 and 64 ABIs

2016-01-27 Thread Moore, Catherine



> -Original Message-
> From: Andrew Bennett [mailto:andrew.benn...@imgtec.com]
> Sent: Wednesday, January 20, 2016 9:42 AM
> To: Matthew Fortune; gcc-patches@gcc.gnu.org
> Cc: Moore, Catherine
> Subject: RE: [PATCH] MIPS: Prevent the p5600-bonding.c test from being run
> for the n32 and 64 ABIs
> 
> Ping.
> 

This is OK now.

> 
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org
> > [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Andrew Bennett
> > Sent: 02 September 2015 14:55
> > To: Matthew Fortune; gcc-patches@gcc.gnu.org
> > Cc: Moore, Catherine (catherine_mo...@mentor.com)
> > Subject: RE: [PATCH] MIPS: Prevent the p5600-bonding.c test from being
> > run for the n32 and 64 ABIs
> >
> > > > diff --git a/gcc/testsuite/gcc.target/mips/p5600-bonding.c
> > > > b/gcc/testsuite/gcc.target/mips/p5600-bonding.c
> > > > index 0890ffa..20c26ca 100644
> > > > --- a/gcc/testsuite/gcc.target/mips/p5600-bonding.c
> > > > +++ b/gcc/testsuite/gcc.target/mips/p5600-bonding.c
> > > > @@ -1,6 +1,7 @@
> > > >  /* { dg-do compile } */
> > > >  /* { dg-options "-dp -mtune=p5600  -mno-micromips -mno-mips16" }
> > > > */
> > > >  /* { dg-skip-if "Bonding needs peephole optimization." { *-*-* } { 
> > > > "-O0"
> > "-
> > > O1" } { "" } }
> > > > */
> > > > +/* { dg-skip-if "There is no DI mode support for load/store
> > > > +bonding" { *-
> > *-
> > > * } { "-
> > > > mabi=n32" "-mabi=64" } { "" } } */  typedef int VINT32
> > > > __attribute__ ((vector_size((16;
> > >
> > > If the best fix we can do for this test is to limit what it tests
> > > then we should still not just skip it. There is some precedence for
> > > tests that require a specific arch with the isa=loongson special
> > > case. I'd rather just lock the test down to p5600 as per the filename.
> >
> > I have changed the testcase's dg-options so that it is only built for p5600.
> > The updated patch and ChangeLog are below.
> >
> > Ok to commit?
> >
> > Many thanks,
> >
> >
> >
> > Andrew
> >
> >
> > testsuite/
> > * gcc.target/mips/p5600-bonding.c (dg-options): Force the test to be
> > always
> > built for p5600.
> > * gcc.target/mips/mips.exp (mips-dg-options): Add support for the
> > isa=p5600
> > dg-option.
> >
> >
> > diff --git a/gcc/testsuite/gcc.target/mips/mips.exp
> > b/gcc/testsuite/gcc.target/mips/mips.exp
> > index 42e7fff..e8d1895 100644
> > --- a/gcc/testsuite/gcc.target/mips/mips.exp
> > +++ b/gcc/testsuite/gcc.target/mips/mips.exp
> > @@ -142,6 +142,9 @@
> >  #   isa=loongson
> >  #  select a Loongson processor
> >  #
> > +#   isa=p5600
> > +#  select a P5600 processor
> > +#
> >  #   addressing=absolute
> >  #  force absolute addresses to be used
> >  #
> > @@ -1009,6 +1012,10 @@ proc mips-dg-options { args } {
> > if { ![regexp {^-march=loongson} $arch] } {
> > set arch "-march=loongson2f"
> > }
> > +   } elseif { [string equal $spec "isa=p5600"] } {
> > +   if { ![regexp {^-march=p5600} $arch] } {
> > +   set arch "-march=p5600"
> > +   }
> > } else {
> > if { ![regexp {^(isa(?:|_rev))(=|<=|>=)([0-9]*)$} \
> >$spec dummy prop relation value nocpus] } {
> > diff --git a/gcc/testsuite/gcc.target/mips/p5600-bonding.c
> > b/gcc/testsuite/gcc.target/mips/p5600-bonding.c
> > index 0890ffa..0bc6d91 100644
> > --- a/gcc/testsuite/gcc.target/mips/p5600-bonding.c
> > +++ b/gcc/testsuite/gcc.target/mips/p5600-bonding.c
> > @@ -1,5 +1,5 @@
> >  /* { dg-do compile } */
> > -/* { dg-options "-dp -mtune=p5600  -mno-micromips -mno-mips16" } */
> > +/* { dg-options "-dp isa=p5600 -mtune=p5600 -mno-micromips
> > +-mno-mips16" } */
> >  /* { dg-skip-if "Bonding needs peephole optimization." { *-*-* } {
> > "-O0" "- O1" } { "" } } */  typedef int VINT32 __attribute__
> > ((vector_size((16;

RE: [RFA] Compact EH Patch [Ping^3]

2016-01-18 Thread Moore, Catherine



> -Original Message-
> From: Moore, Catherine
> Sent: Tuesday, January 05, 2016 8:53 AM
> To: Richard Henderson; ja...@redhat.com
> Cc: gcc-patches@gcc.gnu.org
> Subject: FW: [RFA] Compact EH Patch [Ping * 2]
> 
> Ping, Ping.
> 
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Moore, Catherine
> Sent: Monday, December 21, 2015 9:22 AM
> To: Richard Henderson; gcc-patches@gcc.gnu.org
> Cc: ja...@redhat.com; Matthew Fortune
> Subject: RE: [RFA] Compact EH Patch [Ping]
> 
> 
> 
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of Moore, Catherine
> > Sent: Sunday, December 13, 2015 5:12 PM
> > To: Richard Henderson; gcc-patches@gcc.gnu.org
> > Cc: ja...@redhat.com; Matthew Fortune
> > Subject: RE: [RFA] Compact EH Patch
> >
> > I've now updated the patch.  I'd like to get this in GCC 6.0; please
> > let me know if that is possible.
> > I've also updated the spec (https://github.com/MentorEmbedded/cxx-
> > abi/MIPSCompactEH.pdf).
> >  rth commented that there was no versioning info provision for the
> > personality routines.  The now spec identifies a couple of bits in the
> > header that can be used for that.  A couple of new unwind opcodes were
> > also added.
> >
> > With the exception of Matthew's comment about disabling Compact EH for
> > those ABIs that don't support it, I have not addressed the
> > MIPS-specific comments.  I will post a follow-on patch next week to take
> care of that.
> > There is also a problem with N64 ABI support that requires a follow-on
> > binutils patch.  I have disabled Compact EH for N64 on Linux in this
> > version of the patch.  I plan to re-enable it after binutils is updated.
> >
> > Okay to commit?
> >
> > Thanks,
> > Catherine
> >
> >
> > > -Original Message-
> > > From: Richard Henderson [mailto:r...@redhat.com]
> > > Sent: Friday, September 18, 2015 3:25 PM
> > > To: Moore, Catherine; gcc-patches@gcc.gnu.org
> > > Cc: ja...@redhat.com; Matthew Fortune
> > > Subject: Re: [RFA] Compact EH Patch
> > >
> > > > Index: libgcc/libgcc-std.ver.in
> > > >
> > >
> >
> ==
> > > =
> > > > --- libgcc/libgcc-std.ver.in(revision 226409)
> > > > +++ libgcc/libgcc-std.ver.in(working copy)
> > > > @@ -1918,6 +1918,7 @@ GCC_4.6.0 {
> > > >__morestack_current_segment
> > > >__morestack_initial_sp
> > > >__splitstack_find
> > > > +  _Unwind_GetEhEncoding
> > > >  }
> > > >
> > > >  %inherit GCC_4.7.0 GCC_4.6.0
> > > > @@ -1938,3 +1939,8 @@ GCC_4.7.0 {
> > > >  %inherit GCC_4.8.0 GCC_4.7.0
> > > >  GCC_4.8.0 {
> > > >  }
> > > > +
> > > > +%inherit GCC_4.8.0 GCC_4.7.0
> > > > +GCC_4.8.0 {
> > > > +  __register_frame_info_header_bases
> > > > +}
> > >
> > > You can't push new symbols into old versions.  These have to go into
> > > the version for the current gcc.
> >
> > Done.
> > >
> > > > Index: libstdc++-v3/config/abi/pre/gnu.ver
> > > >
> > >
> >
> ==
> > > =
> > > > --- libstdc++-v3/config/abi/pre/gnu.ver (revision 226409)
> > > > +++ libstdc++-v3/config/abi/pre/gnu.ver (working copy)
> > > > @@ -1909,6 +1909,7 @@ CXXABI_1.3 {
> > > >  __gxx_personality_v0;
> > > >  __gxx_personality_sj0;
> > > >  __gxx_personality_seh0;
> > > > +__gnu_compact_pr2;
> > > >  __dynamic_cast;
> > > >
> > > >  # *_type_info classes, ctor and dtor
> >
> > Done.
> >
> > > > Index: libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> > > >
> > >
> >
> ==
> > > =
> > > > --- libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> > >   (revision 226409)
> > > > +++ libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> > >   (working copy)
> > > > @@ -200,6 +200,7 @@ CXXABI_2.0 {
> > > >  __cxa_vec_new;
> > > >  __gxx_personality_v0;
> > > >

RE: Ping Re: Handle Octeon 3 not supporting MIPS paired-single instructions

2016-01-15 Thread Moore, Catherine



> -Original Message-
> From: Myers, Joseph
> Sent: Friday, January 15, 2016 6:28 PM
> To: Andrew Pinski
> Cc: GCC Patches; Moore, Catherine; matthew.fort...@imgtec.com
> Subject: Ping Re: Handle Octeon 3 not supporting MIPS paired-single
> instructions
> 
> On Fri, 8 Jan 2016, Andrew Pinski wrote:
> 
> > On Fri, Jan 8, 2016 at 4:05 PM, Joseph Myers <jos...@codesourcery.com>
> wrote:
> > > The Octeon 3 processor does not support the MIPS paired-single
> > > instructions.  This results in illegal instruction errors in the
> > > testsuite when vectorization tests try to use those instructions.
> > >
> > > This patch teaches the compiler about that lack of support, so that
> > > warnings are given when -mpaired-single (or something implying it)
> > > is used when compiling for such a processor.  I chose to test
> > > TARGET_OCTEON as the simplest conditional; since the older Octeon
> > > processors don't support hard float at all, I don't think the choice
> > > matters for them.  Tests that then failed with the warning were
> > > updated to disable them for Octeon.
> > >
> > > Tested with no regressions for cross to mips64el-linux-gnu (Octeon
> > > 3).  OK to commit?
> >
> > This is ok from my point of view.  I did not think about doing this at
> > the time I added Octeon 3 support.
> 
> Ping for MIPS maintainer review of this patch <https://gcc.gnu.org/ml/gcc-
> patches/2016-01/msg00492.html>.
> 
This is OK, please commit.
Thanks,
Catherine

RE: [PATCH][MIPS] Migrate reduction optabs in mips-ps-3d.md

2016-01-14 Thread Moore, Catherine



> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Thursday, January 14, 2016 5:49 AM
> To: Alan Lawrence; Moore, Catherine
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH][MIPS] Migrate reduction optabs in mips-ps-3d.md
> 
> Alan Lawrence <alan.lawre...@foss.arm.com> writes:
> > On 07/01/16 12:47, Alan Lawrence wrote:
> > > Here's an updated version, also covering the min/max patterns I
> > > missed
> > before.
> > > I've now managed to do some testing with a stage 1 compiler, by
> > > compiling all tests in gcc.dg/vect at -O2 -ftree-vectorize -mips3d
> > > -march=mips64r2 -mabi=n32 $x -ffast-math -ffinite-math-only.
> > >
> > > There were no changes in which files compiled (871 did, some did not
> > > due to libraries etc. missing in my stage 1 compiler), and no
> > > changes in any assembly output. The patterns were triggered on:
> > >
> > > fast-math-vect-reduc-5.c, fast-math-vect-reduc-8.c,
> > > fast-math-vect-reduc-9.c, no-fast-math-vect16.c, pr66142.c,
> > > vect-outer-fir-big-array.c, vect-outer-fir.c,
> > > vect-outer-fir-lb-big-array.c, vect-outer-fir-lb.c, vect-reduc-10.c,
> > > vect-reduc-6.c
> > >
> > > I realize this is not completely representative of a 'proper' test
> > > run, in which different files are compiled with different options,
> > > but it provides reasonable confidence that I'm not changing any code
> > generation.
> > >
> > > OK for trunk? (stage 3?)
> >
> > Ping.
> 
> I don't have any particularly better way of testing this set up at the moment.
> The change looks OK to me.
> 
> Catherine: Do you have anything you can test this on? If not then I think we
> just do the change on the basis of the testing Alan has done.
> 
I don't have a suitable board.  Alan, please go ahead and commit.
Thanks,
Catherine

> 
> >
> > > gcc/ChangeLog:
> > >
> > >   * config/mips/mips-ps-3d.md (reduc_splus_v2sf): Remove.
> > >   (reduc_plus_scal_v2sf): New.
> > >   (reduc_smax_v2sf): Rename to...
> > >   (reduc_smax_scal_v2sf): ...here, make result SFmode, add
> > vec_extract.
> > >   (reduc_smin_v2sf): Rename to...
> > >   (reduc_smin_scal_v2sf): ...here, make result SFmode, add
> > vec_extract.
> > > ---
> > >   gcc/config/mips/mips-ps-3d.md | 34
> > > ++---
> > -
> > >   1 file changed, 22 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/gcc/config/mips/mips-ps-3d.md
> > > b/gcc/config/mips/mips-ps-3d.md index 8bc7608..a93a2b9 100644
> > > --- a/gcc/config/mips/mips-ps-3d.md
> > > +++ b/gcc/config/mips/mips-ps-3d.md
> > > @@ -371,13 +371,17 @@
> > > [(set_attr "type" "fadd")
> > >  (set_attr "mode" "SF")])
> > >
> > > -(define_insn "reduc_splus_v2sf"
> > > -  [(set (match_operand:V2SF 0 "register_operand" "=f")
> > > - (unspec:V2SF [(match_operand:V2SF 1 "register_operand" "f")
> > > -   (match_dup 1)]
> > > -  UNSPEC_ADDR_PS))]
> > > +(define_expand "reduc_plus_scal_v2sf"
> > > +  [(match_operand:SF 0 "register_operand" "=f")
> > > +   (match_operand:V2SF 1 "register_operand" "f")]
> > > "TARGET_HARD_FLOAT && TARGET_MIPS3D"
> > > -  "")
> > > +  {
> > > +rtx temp = gen_reg_rtx (V2SFmode);
> > > +emit_insn (gen_mips_addr_ps (temp, operands[1], operands[1]));
> > > +rtx lane = BYTES_BIG_ENDIAN ? const1_rtx : const0_rtx;
> > > +emit_insn (gen_vec_extractv2sf (operands[0], temp, lane));
> > > +DONE;
> > > +  })
> > >
> > >   ; cvt.pw.ps - Floating Point Convert Paired Single to Paired Word
> > >   (define_insn "mips_cvt_pw_ps"
> > > @@ -745,20 +749,26 @@
> > > DONE;
> > >   })
> > >
> > > -(define_expand "reduc_smin_v2sf"
> > > -  [(match_operand:V2SF 0 "register_operand")
> > > +(define_expand "reduc_smin_scal_v2sf"
> > > +  [(match_operand:SF 0 "register_operand")
> > >  (match_operand:V2SF 1 "register_operand")]
> > > "TARGET_HARD_FLOAT && TARGET_PAIRED_SINGLE_FLOAT"
> > >   {
> > > -  mips_expand_vec_reduc (operands[0], operands[1], gen_sminv2sf3);
> > > +  rtx temp = gen_reg_rtx (V2SFmode);  mips_expand_vec_reduc (temp,
> > > + operands[1], gen_sminv2sf3);  rtx lane = BYTES_BIG_ENDIAN ?
> > > + const1_rtx : const0_rtx;  emit_insn (gen_vec_extractv2sf
> > > + (operands[0], temp, lane));
> > > DONE;
> > >   })
> > >
> > > -(define_expand "reduc_smax_v2sf"
> > > -  [(match_operand:V2SF 0 "register_operand")
> > > +(define_expand "reduc_smax_scal_v2sf"
> > > +  [(match_operand:SF 0 "register_operand")
> > >  (match_operand:V2SF 1 "register_operand")]
> > > "TARGET_HARD_FLOAT && TARGET_PAIRED_SINGLE_FLOAT"
> > >   {
> > > -  mips_expand_vec_reduc (operands[0], operands[1], gen_smaxv2sf3);
> > > +  rtx temp = gen_reg_rtx (V2SFmode);  mips_expand_vec_reduc (temp,
> > > + operands[1], gen_smaxv2sf3);  rtx lane = BYTES_BIG_ENDIAN ?
> > > + const1_rtx : const0_rtx;  emit_insn (gen_vec_extractv2sf
> > > + (operands[0], temp, lane));
> > > DONE;
> > >   })
> > >

RE: [PATCH][MIPS] Reorder function types

2016-01-05 Thread Moore, Catherine



> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Tuesday, January 05, 2016 11:45 AM
> To: Robert Suchanek; Moore, Catherine
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH][MIPS] Reorder function types
> 
> Robert Suchanek <robert.sucha...@imgtec.com> writes:
> > gcc/
> > * config/mips/mips-ftypes.def: Sort to lexicographical order.
> 
> The patch is fine. I don't know what we can/should commit at this stage.
> Catherine: Any idea what is acceptable? I'd think this kind of small change to
> be OK and make it easier to maintain MSA out of tree given I doubt it can be
> committed now.
> 
This is fine to commit now.

FW: [RFA] Compact EH Patch [Ping * 2]

2016-01-05 Thread Moore, Catherine

Ping, Ping.

-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On 
Behalf Of Moore, Catherine
Sent: Monday, December 21, 2015 9:22 AM
To: Richard Henderson; gcc-patches@gcc.gnu.org
Cc: ja...@redhat.com; Matthew Fortune
Subject: RE: [RFA] Compact EH Patch [Ping]



> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- 
> ow...@gcc.gnu.org] On Behalf Of Moore, Catherine
> Sent: Sunday, December 13, 2015 5:12 PM
> To: Richard Henderson; gcc-patches@gcc.gnu.org
> Cc: ja...@redhat.com; Matthew Fortune
> Subject: RE: [RFA] Compact EH Patch
> 
> I've now updated the patch.  I'd like to get this in GCC 6.0; please 
> let me know if that is possible.
> I've also updated the spec (https://github.com/MentorEmbedded/cxx-
> abi/MIPSCompactEH.pdf).
>  rth commented that there was no versioning info provision for the 
> personality routines.  The now spec identifies a couple of bits in the 
> header that can be used for that.  A couple of new unwind opcodes were 
> also added.
> 
> With the exception of Matthew's comment about disabling Compact EH for 
> those ABIs that don't support it, I have not addressed the 
> MIPS-specific comments.  I will post a follow-on patch next week to take care 
> of that.
> There is also a problem with N64 ABI support that requires a follow-on 
> binutils patch.  I have disabled Compact EH for N64 on Linux in this 
> version of the patch.  I plan to re-enable it after binutils is updated.
> 
> Okay to commit?
> 
> Thanks,
> Catherine
> 
> 
> > -Original Message-
> > From: Richard Henderson [mailto:r...@redhat.com]
> > Sent: Friday, September 18, 2015 3:25 PM
> > To: Moore, Catherine; gcc-patches@gcc.gnu.org
> > Cc: ja...@redhat.com; Matthew Fortune
> > Subject: Re: [RFA] Compact EH Patch
> >
> > > Index: libgcc/libgcc-std.ver.in
> > >
> >
> ==
> > =
> > > --- libgcc/libgcc-std.ver.in  (revision 226409)
> > > +++ libgcc/libgcc-std.ver.in  (working copy)
> > > @@ -1918,6 +1918,7 @@ GCC_4.6.0 {
> > >__morestack_current_segment
> > >__morestack_initial_sp
> > >__splitstack_find
> > > +  _Unwind_GetEhEncoding
> > >  }
> > >
> > >  %inherit GCC_4.7.0 GCC_4.6.0
> > > @@ -1938,3 +1939,8 @@ GCC_4.7.0 {
> > >  %inherit GCC_4.8.0 GCC_4.7.0
> > >  GCC_4.8.0 {
> > >  }
> > > +
> > > +%inherit GCC_4.8.0 GCC_4.7.0
> > > +GCC_4.8.0 {
> > > +  __register_frame_info_header_bases
> > > +}
> >
> > You can't push new symbols into old versions.  These have to go into 
> > the version for the current gcc.
> 
> Done.
> >
> > > Index: libstdc++-v3/config/abi/pre/gnu.ver
> > >
> >
> ==
> > =
> > > --- libstdc++-v3/config/abi/pre/gnu.ver   (revision 226409)
> > > +++ libstdc++-v3/config/abi/pre/gnu.ver   (working copy)
> > > @@ -1909,6 +1909,7 @@ CXXABI_1.3 {
> > >  __gxx_personality_v0;
> > >  __gxx_personality_sj0;
> > >  __gxx_personality_seh0;
> > > +__gnu_compact_pr2;
> > >  __dynamic_cast;
> > >
> > >  # *_type_info classes, ctor and dtor
> 
> Done.
> 
> > > Index: libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> > >
> >
> ==
> > =
> > > --- libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> > (revision 226409)
> > > +++ libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> > (working copy)
> > > @@ -200,6 +200,7 @@ CXXABI_2.0 {
> > >  __cxa_vec_new;
> > >  __gxx_personality_v0;
> > >  __gxx_personality_sj0;
> > > +__gnu_compact_pr2;
> > >  __dynamic_cast;
> > >
> > >  # std::exception_ptr
> >
> Jonathan says that CXXABI_2.0 is correct here.
> >
> > > +  if (data.type != CET_not_found)
> > > +return data.type;
> > > +
> > > +  return CET_not_found;
> >
> > Return data.type unconditionally.
> 
> Done.
> >
> > > +++ libgcc/unwind-pe.h(working copy)
> > > @@ -44,6 +44,7 @@
> > >  #define DW_EH_PE_udata2 0x02
> > >  #define DW_EH_PE_udata4 0x03
> > >  #define DW_EH_PE_udata8 0x04
> > > +#define DW_EH_PE_udata1 0x05
> > >  #defi

RE: [BUILDROBOT] "error: null argument where non-null required" on multiple targets

2015-12-21 Thread Moore, Catherine



> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Thursday, December 17, 2015 1:06 PM
> To: Jan-Benedict Glaw
> Cc: Moore, Catherine; Denis Chertykov; Eric Christopher; Matthew Fortune;
> David Edelsohn; Alexandre Oliva; Kaz Kojima; Oleg Endo; Jonathan Wakely;
> gcc-patches
> Subject: Re: [BUILDROBOT] "error: null argument where non-null required"
> on multiple targets
> 
> On 12/16/2015 03:46 AM, Jan-Benedict Glaw wrote:
> > On Tue, 2015-12-15 10:43:58 -0700, Jeff Law <l...@redhat.com> wrote:
> >> On 12/14/2015 01:07 PM, Jan-Benedict Glaw wrote:
> >>> On Mon, 2015-12-14 18:54:28 +, Moore, Catherine
> <catherine_mo...@mentor.com> wrote:
> >>>> Is there an easy way to reproduce the MIPS problems that you
> >>>> reported?  I don't seem to be able to do it with a cross-compiler
> >>>> targeting mipsel-elf.
> >>>
> >>> What's your build compiler? For these builds, where it showed up,
> >>> I'm using a freshly compiles HEAD/master version. So basically,
> >>> compile a current GCC for your build machine:
> >> Right.  This is something that only shows up when using the trunk to
> >> build the crosses.
> >>
Thanks -- I have now reproduced the problem.

RE: [RFA] Compact EH Patch [Ping]

2015-12-21 Thread Moore, Catherine



> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Moore, Catherine
> Sent: Sunday, December 13, 2015 5:12 PM
> To: Richard Henderson; gcc-patches@gcc.gnu.org
> Cc: ja...@redhat.com; Matthew Fortune
> Subject: RE: [RFA] Compact EH Patch
> 
> I've now updated the patch.  I'd like to get this in GCC 6.0; please let me
> know if that is possible.
> I've also updated the spec (https://github.com/MentorEmbedded/cxx-
> abi/MIPSCompactEH.pdf).
>  rth commented that there was no versioning info provision for the
> personality routines.  The now spec identifies a couple of bits in the header
> that can be used for that.  A couple of new unwind opcodes were also
> added.
> 
> With the exception of Matthew's comment about disabling Compact EH for
> those ABIs that don't support it, I have not addressed the MIPS-specific
> comments.  I will post a follow-on patch next week to take care of that.
> There is also a problem with N64 ABI support that requires a follow-on
> binutils patch.  I have disabled Compact EH for N64 on Linux in this version 
> of
> the patch.  I plan to re-enable it after binutils is updated.
> 
> Okay to commit?
> 
> Thanks,
> Catherine
> 
> 
> > -Original Message-
> > From: Richard Henderson [mailto:r...@redhat.com]
> > Sent: Friday, September 18, 2015 3:25 PM
> > To: Moore, Catherine; gcc-patches@gcc.gnu.org
> > Cc: ja...@redhat.com; Matthew Fortune
> > Subject: Re: [RFA] Compact EH Patch
> >
> > > Index: libgcc/libgcc-std.ver.in
> > >
> >
> ==
> > =
> > > --- libgcc/libgcc-std.ver.in  (revision 226409)
> > > +++ libgcc/libgcc-std.ver.in  (working copy)
> > > @@ -1918,6 +1918,7 @@ GCC_4.6.0 {
> > >__morestack_current_segment
> > >__morestack_initial_sp
> > >__splitstack_find
> > > +  _Unwind_GetEhEncoding
> > >  }
> > >
> > >  %inherit GCC_4.7.0 GCC_4.6.0
> > > @@ -1938,3 +1939,8 @@ GCC_4.7.0 {
> > >  %inherit GCC_4.8.0 GCC_4.7.0
> > >  GCC_4.8.0 {
> > >  }
> > > +
> > > +%inherit GCC_4.8.0 GCC_4.7.0
> > > +GCC_4.8.0 {
> > > +  __register_frame_info_header_bases
> > > +}
> >
> > You can't push new symbols into old versions.  These have to go into
> > the version for the current gcc.
> 
> Done.
> >
> > > Index: libstdc++-v3/config/abi/pre/gnu.ver
> > >
> >
> ==
> > =
> > > --- libstdc++-v3/config/abi/pre/gnu.ver   (revision 226409)
> > > +++ libstdc++-v3/config/abi/pre/gnu.ver   (working copy)
> > > @@ -1909,6 +1909,7 @@ CXXABI_1.3 {
> > >  __gxx_personality_v0;
> > >  __gxx_personality_sj0;
> > >  __gxx_personality_seh0;
> > > +__gnu_compact_pr2;
> > >  __dynamic_cast;
> > >
> > >  # *_type_info classes, ctor and dtor
> 
> Done.
> 
> > > Index: libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> > >
> >
> ==
> > =
> > > --- libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> > (revision 226409)
> > > +++ libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> > (working copy)
> > > @@ -200,6 +200,7 @@ CXXABI_2.0 {
> > >  __cxa_vec_new;
> > >  __gxx_personality_v0;
> > >  __gxx_personality_sj0;
> > > +__gnu_compact_pr2;
> > >  __dynamic_cast;
> > >
> > >  # std::exception_ptr
> >
> Jonathan says that CXXABI_2.0 is correct here.
> >
> > > +  if (data.type != CET_not_found)
> > > +return data.type;
> > > +
> > > +  return CET_not_found;
> >
> > Return data.type unconditionally.
> 
> Done.
> >
> > > +++ libgcc/unwind-pe.h(working copy)
> > > @@ -44,6 +44,7 @@
> > >  #define DW_EH_PE_udata2 0x02
> > >  #define DW_EH_PE_udata4 0x03
> > >  #define DW_EH_PE_udata8 0x04
> > > +#define DW_EH_PE_udata1 0x05
> > >  #define DW_EH_PE_sleb1280x09
> > >  #define DW_EH_PE_sdata2 0x0A
> > >  #define DW_EH_PE_sdata4 0x0B
> >
> > If we're going to add udata1, we might as well add sdata1 for consistency.
> 
> Done.
> >
> > > @@ -184,6 +187,7 @@ read_encoded_value_with_base (unsign

RE: [Patch] Fix for MIPS PR target/65604

2015-12-16 Thread Moore, Catherine



> -Original Message-
> From: Steve Ellcey [mailto:sell...@imgtec.com]
> Sent: Tuesday, December 15, 2015 4:09 PM
> To: Moore, Catherine
> Cc: gcc-patches@gcc.gnu.org; matthew.fort...@imgtec.com
> Subject: RE: [Patch] Fix for MIPS PR target/65604
> 
> On Tue, 2015-12-15 at 15:13 +, Moore, Catherine wrote:
> 
> >
> > HI Steve, The patch is OK.  Will you please add a test case and repost?
> > Thanks,
> > Catherine
> 
> Here is the patch with a test case.
> 

Looks good, thanks.

RE: [Patch] Fix for MIPS PR target/65604

2015-12-15 Thread Moore, Catherine



> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Steve Ellcey
> Sent: Wednesday, December 09, 2015 1:34 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Moore, Catherine; matthew.fort...@imgtec.com
> Subject: [Patch] Fix for MIPS PR target/65604
> 
> This is a MIPS patch to make mips_output_division obey the -fno-delayed-
> branch flag.  Right now, with mips1 and -mcheck-zero-division, the division
> instruction is put into the bne delay slot even when -fno-delayed-branch is
> specified.  This change uses a similar strategy to MIPS16 where we do the
> division first and then do the zero test while the division is being 
> calculated.
> Tested with mips1 runs and by inspecting the code that is output.
> 
> OK to checkin?
> 
> Steve Ellcey
> sell...@imgtec.com
> 
> 
> 2015-12-09  Steve Ellcey  <sell...@imgtec.com>
> 
>   PR target/65604
>   * config/mips/mips.c (mips_output_division): Check
> flag_delayed_branch.
> 

HI Steve, The patch is OK.  Will you please add a test case and repost?
Thanks,
Catherine

RE: [BUILDROBOT] "error: null argument where non-null required" on multiple targets

2015-12-14 Thread Moore, Catherine



> -Original Message-
> From: Jan-Benedict Glaw [mailto:jbg...@lug-owl.de]
> Sent: Sunday, December 06, 2015 4:49 PM
> To: Denis Chertykov; Moore, Catherine; Eric Christopher; Matthew Fortune;
> David Edelsohn; Alexandre Oliva; Kaz Kojima; Oleg Endo
> Cc: Jonathan Wakely; gcc-patches
> Subject: [BUILDROBOT] "error: null argument where non-null required" on
> multiple targets
> 
> Hi!
> 
> I'm not 100% sure, but I *think* that this patch
> 
>   2015-11-15  Jonathan Wakely  <jwak...@redhat.com>
> 
>   PR libstdc++/68353
>   * include/bits/basic_string.h: Test value of
> _GLIBCXX_USE_C99_WCHAR
>   not whether it is defined.
>   * include/ext/vstring.h: Likewise.
> 
> uncovered errors like this:
> 
> /---
> | g++ -fno-PIE -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -
> DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti -
> fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -
> Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -
> Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-
> common  -DHAVE_CONFIG_H -I. -Ic-family -I../../../gcc/gcc -
> I../../../gcc/gcc/c-family -I../../../gcc/gcc/../include -
> I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include  -
> I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -
> I../libdecnumber -I../../../gcc/gcc/../libbacktrace   -o c-family/c-common.o -
> MT c-family/c-common.o -MMD -MP -MF c-family/.deps/c-common.TPo
> ../../../gcc/gcc/c-family/c-common.c
> | In file included from ../../../gcc/gcc/c-family/c-common.c:31:0:
> | ../../../gcc/gcc/c-family/c-common.c: In function ‘void
> c_common_nodes_and_builtins()’:
> | ../../../gcc/gcc/stringpool.h:39:53: error: null argument where non-null
> required (argument 1) [-Werror=nonnull]
> |  ? get_identifier_with_length ((str), strlen (str))  \
> |  ^
> |
> | ../../../gcc/gcc/c-family/c-common.c:5501:22: note: in expansion of macro
> ‘get_identifier’
> |char32_type_node = get_identifier (CHAR32_TYPE);
> |   ^~
> |
> | cc1plus: all warnings being treated as errors
> | Makefile:1085: recipe for target 'c-family/c-common.o' failed
> \---
> 
> Shows up when using a newly build compiler to build the contrib/config-
> list.mk targets. So these targets probably need some small touch-ups.
> 
> avr-rtems http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478544
> mipsel-elfhttp://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478844
> mipsisa64r2-sde-elf   http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478855
> mipsisa64sb1-elf  http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478865
> mips-rtemshttp://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478877
> powerpc-eabialtivec   http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478922
> powerpc-eabispe   http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478932
> powerpc-rtems http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478956
> ppc-elf   http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=478968
> sh-superh-elf http://toolchain.lug-
> owl.de/buildbot/show_build_details.php?id=479077
> 

Is there an easy way to reproduce the MIPS problems that you reported?  I don't 
seem to be able to do it with a cross-compiler targeting mipsel-elf.
Thanks,
Catherine

RE: [mips] Rotate stack checking loop

2015-12-02 Thread Moore, Catherine



> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Eric Botcazou
> Sent: Thursday, November 12, 2015 4:51 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [mips] Rotate stack checking loop
> 
> Hi,
> 
> this patch rotates the loop generated in the prologue to do stack checking
> when -fstack-check is specified, thereby saving one branch instruction.  It
> was initially implemented as a WHILE loop to match the generic
> implementation but can be turned into a DO-WHILE loop because the
> amount of stack to be checked is known at compile time (since it's the static
> part of the frame).
> 
> Unfortunately I don't have access to MIPS hardware any more so I only
> verified
> that the assembly code is as expected and can be assembled.   OK for
> mainline?
> 
> 
> 2015-11-12  Eric Botcazou  
> 
>   * config/mips/mips.c (mips_emit_probe_stack_range): Adjust.
>   (mips_output_probe_stack_range): Rotate the loop and simplify.
> 
This is OK.

RE: [RFA] Compact EH Patch

2015-12-01 Thread Moore, Catherine

Ping?

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Moore, Catherine
> Sent: Wednesday, November 25, 2015 11:58 AM
> To: Richard Henderson; gcc-patches@gcc.gnu.org
> Cc: ja...@redhat.com; Matthew Fortune
> Subject: RE: [RFA] Compact EH Patch
> 
> 
> 
> > -Original Message-
> > From: Richard Henderson [mailto:r...@redhat.com]
> > Sent: Friday, September 18, 2015 3:25 PM
> > To: Moore, Catherine; gcc-patches@gcc.gnu.org
> > Cc: ja...@redhat.com; Matthew Fortune
> > Subject: Re: [RFA] Compact EH Patch
> >
> > > Index: libgcc/libgcc-std.ver.in
> > >
> >
> ==
> > =
> > > --- libgcc/libgcc-std.ver.in  (revision 226409)
> > > +++ libgcc/libgcc-std.ver.in  (working copy)
> > > @@ -1918,6 +1918,7 @@ GCC_4.6.0 {
> > >__morestack_current_segment
> > >__morestack_initial_sp
> > >__splitstack_find
> > > +  _Unwind_GetEhEncoding
> > >  }
> > >
> > >  %inherit GCC_4.7.0 GCC_4.6.0
> > > @@ -1938,3 +1939,8 @@ GCC_4.7.0 {
> > >  %inherit GCC_4.8.0 GCC_4.7.0
> > >  GCC_4.8.0 {
> > >  }
> > > +
> > > +%inherit GCC_4.8.0 GCC_4.7.0
> > > +GCC_4.8.0 {
> > > +  __register_frame_info_header_bases
> > > +}
> >
> > You can't push new symbols into old versions.  These have to go into
> > the version for the current gcc.
> >
> > > Index: libstdc++-v3/config/abi/pre/gnu.ver
> > >
> >
> ==
> > =
> > > --- libstdc++-v3/config/abi/pre/gnu.ver   (revision 226409)
> > > +++ libstdc++-v3/config/abi/pre/gnu.ver   (working copy)
> > > @@ -1909,6 +1909,7 @@ CXXABI_1.3 {
> > >  __gxx_personality_v0;
> > >  __gxx_personality_sj0;
> > >  __gxx_personality_seh0;
> > > +__gnu_compact_pr2;
> > >  __dynamic_cast;
> > >
> > >  # *_type_info classes, ctor and dtor
> > > Index: libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> > >
> >
> ==
> > =
> > > --- libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> > (revision 226409)
> > > +++ libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> > (working copy)
> > > @@ -200,6 +200,7 @@ CXXABI_2.0 {
> > >  __cxa_vec_new;
> > >  __gxx_personality_v0;
> > >  __gxx_personality_sj0;
> > > +__gnu_compact_pr2;
> > >  __dynamic_cast;
> > >
> > >  # std::exception_ptr
> >
> > Likewise.
> >
> I'm getting ready to post the updates to this patch -- hopefully, I can still 
> get it
> in GCC 6.0.
> I'm not sure how to tell what the current CXXABI is for these two files.
> Should it be CXXABI_2.0 for both of these?
> Thanks,
> Catherine

RE: [PATCH] MIPS/GCC/doc: Reorder `-mcompact-branches='

2015-11-26 Thread Moore, Catherine



> -Original Message-
> From: Maciej W. Rozycki [mailto:ma...@imgtec.com]
> Sent: Thursday, November 26, 2015 9:01 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Moore, Catherine; Matthew Fortune
> Subject: [PATCH] MIPS/GCC/doc: Reorder `-mcompact-branches='
> 
> Move the `-mcompact-branches=' option out of the middle of a block of
> floating-point options.  The option is not related to FP in any way.
> Place it immediately below other branch instruction selection options.
> 
>   gcc/
>   * doc/invoke.texi (Option Summary) : Reorder
>   `-mcompact-branches='.
>   (MIPS Options): Likewise.
> ---
> 
>  OK to apply?
> 
 Yes -- thanks.

RE: [RFA] Compact EH Patch

2015-11-25 Thread Moore, Catherine



> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Friday, September 18, 2015 3:25 PM
> To: Moore, Catherine; gcc-patches@gcc.gnu.org
> Cc: ja...@redhat.com; Matthew Fortune
> Subject: Re: [RFA] Compact EH Patch
> 
> > Index: libgcc/libgcc-std.ver.in
> >
> ==
> =
> > --- libgcc/libgcc-std.ver.in(revision 226409)
> > +++ libgcc/libgcc-std.ver.in(working copy)
> > @@ -1918,6 +1918,7 @@ GCC_4.6.0 {
> >__morestack_current_segment
> >__morestack_initial_sp
> >__splitstack_find
> > +  _Unwind_GetEhEncoding
> >  }
> >
> >  %inherit GCC_4.7.0 GCC_4.6.0
> > @@ -1938,3 +1939,8 @@ GCC_4.7.0 {
> >  %inherit GCC_4.8.0 GCC_4.7.0
> >  GCC_4.8.0 {
> >  }
> > +
> > +%inherit GCC_4.8.0 GCC_4.7.0
> > +GCC_4.8.0 {
> > +  __register_frame_info_header_bases
> > +}
> 
> You can't push new symbols into old versions.  These have to go into the
> version for the current gcc.
> 
> > Index: libstdc++-v3/config/abi/pre/gnu.ver
> >
> ==
> =
> > --- libstdc++-v3/config/abi/pre/gnu.ver (revision 226409)
> > +++ libstdc++-v3/config/abi/pre/gnu.ver (working copy)
> > @@ -1909,6 +1909,7 @@ CXXABI_1.3 {
> >  __gxx_personality_v0;
> >  __gxx_personality_sj0;
> >  __gxx_personality_seh0;
> > +__gnu_compact_pr2;
> >  __dynamic_cast;
> >
> >  # *_type_info classes, ctor and dtor
> > Index: libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> >
> ==
> =
> > --- libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
>   (revision 226409)
> > +++ libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
>   (working copy)
> > @@ -200,6 +200,7 @@ CXXABI_2.0 {
> >  __cxa_vec_new;
> >  __gxx_personality_v0;
> >  __gxx_personality_sj0;
> > +__gnu_compact_pr2;
> >  __dynamic_cast;
> >
> >  # std::exception_ptr
> 
> Likewise.
> 
I'm getting ready to post the updates to this patch -- hopefully, I can still 
get it in GCC 6.0.
I'm not sure how to tell what the current CXXABI is for these two files.  
Should it be CXXABI_2.0 for both of these?
Thanks,
Catherine

RE: [Patch, MIPS] Frame header optimization for MIPS (part 2)

2015-11-24 Thread Moore, Catherine



> -Original Message-
> From: Steve Ellcey [mailto:sell...@imgtec.com]
> Sent: Friday, October 23, 2015 2:08 PM
> To: Myers, Joseph
> Cc: Bernd Schmidt; Mike Stump; gcc-patches@gcc.gnu.org;
> matthew.fort...@imgtec.com; Moore, Catherine
> Subject: Re: [Patch, MIPS] Frame header optimization for MIPS (part 2)
> 
> Just to follow up on this string, here is a new version of the patch
> with the extraneous parenthesis removed.
> 
> Steve Ellcey
> sell...@imgtec.com
> 
> 
> 2015-10-23  Steve Ellcey  <sell...@imgtec.com>
> 
>   * frame-header-opt.c (gate): Check for optimize > 0.
>   (has_inlined_assembly): New function.
>   (needs_frame_header_p): Remove is_leaf_function check,
>   add argument type check.
>   (callees_functions_use_frame_header): Add is_leaf_function
>   and has_inlined_assembly calls..
>   (set_callers_may_not_allocate_frame): New function.
>   (frame_header_opt): Add is_leaf_function call, add
>   set_callers_may_not_allocate_frame call.
>   * config/mips/mips.c (mips_compute_frame_info): Add check
>   to see if callee saved regs can be put in frame header.
>   (mips_expand_prologue): Add check to see if step1 is zero,
>   fix cfa restores when using frame header to store regs.
>   (mips_can_use_return_insn): Check to see if registers are
>   stored in frame header.
>   * config/mips/mips.h (machine_function): Add
>   callers_may_not_allocate_frame and
>   use_frame_header_for_callee_saved_regs fields.

This is okay after making the minor corrections embedded below.
I'm sorry that it took me so long to review this patch.
Catherine

> 
> diff --git a/gcc/config/mips/frame-header-opt.c b/gcc/config/mips/frame-
> header-opt.c
> index 7c7b1f2..2cf589d 100644
> --- a/gcc/config/mips/frame-header-opt.c
> +++ b/gcc/config/mips/frame-header-opt.c
> @@ -125,6 +125,29 @@ is_leaf_function (function *fn)
>return true;
>  }
> 
> +/* Return true if this function has inline assembly code or if we cannot
> +   be certain that it does not.  False if know that there is no inline
> +   assembly.  */
> +

 s/False if know/False if we know/

> @@ -136,20 +159,26 @@ needs_frame_header_p (function *fn)
>if (fn->decl == NULL)
>  return true;
> 
> -  if (fn->stdarg || !is_leaf_function (fn))
> +  if (fn->stdarg)
>  return true;
> 
>for (t = DECL_ARGUMENTS (fn->decl); t; t = TREE_CHAIN (t))
>  {
>if (!use_register_for_decl (t))
> -   return true;
> + return true;
> +
> +  /* Some 64 bit types may get copied to general registers using the 
> frame
> +  header, see mips_output_64bit_xfer.  Checking for SImode only may be
> + overly restrictive but it is gauranteed to be safe. */

  s/64 bit/64-bit/
 s/gauranteed/guaranteed/

> diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
> index c5affc8..5a9d48d 100644
> --- a/gcc/config/mips/mips.c
> +++ b/gcc/config/mips/mips.c
> @@ -10465,6 +10465,35 @@ mips_compute_frame_info (void)
>frame->cop0_sp_offset = offset - UNITS_PER_WORD;
>  }
> 
> +  /* Determine if we can save the callee saved registers in the frame
> + header.  Restrict this to functions where there is no other reason
> + to allocate stack space so that we can completely eliminate the
> + instructions that modify the stack pointer.  */
> +
  s/callee saved/callee-saved/
  s/completely//

> 
> 
> 
> 2015-10-23  Steve Ellcey  <sell...@imgtec.com>
> 
>   * gcc.target/mips/frame-header-4.c: New test.
> 
> diff --git a/gcc/testsuite/gcc.target/mips/frame-header-4.c
> b/gcc/testsuite/gcc.target/mips/frame-header-4.c
> index e69de29..3cddba1 100644
> --- a/gcc/testsuite/gcc.target/mips/frame-header-4.c
> +++ b/gcc/testsuite/gcc.target/mips/frame-header-4.c
> @@ -0,0 +1,20 @@
> +/* Verify that we can optimize away the frame header allocation in bar
> +   by having it use its frame header to store $31 in before calling foo.  */
> +
> +/* { dg-do compile } */
> +/* { dg-options "-mframe-header-opt -mabi=32" } */
> +/* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
> +/* { dg-final { scan-assembler-not "\taddiu\t\\\$sp" } } */
> +
> +int __attribute__ ((noinline))
> +foo (int a, int b)
> +{
> + return a + b;
> +}
> +
> +int  __attribute__ ((noinline))
> +bar (int a, int b)
> +{
> + return 1 + foo(a,b);
> +}
> +

  Space after foo, please.  Change the two tabs to two space each.

RE: [PATCH, MIPS, PR/61114] Migrate to reduc_..._scal optabs.

2015-11-03 Thread Moore, Catherine



> -Original Message-
> From: Simon Dardis [mailto:simon.dar...@imgtec.com]
> Sent: Wednesday, October 07, 2015 6:51 AM
> To: Alan Lawrence; Matthew Fortune; Moore, Catherine
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH, MIPS, PR/61114] Migrate to reduc_..._scal optabs.
> 
> On the change from smin/smax it was a deliberate change as I managed to
> confuse myself of the mode patterns, correct version follows. Reverted back
> to VWHB for smax/smin. Stylistic point addressed.
> 
> No new regression, ok for commit?
> 

Yes, OK to commit.  Sorry for the delay in review.
Catherine

> 
> Index: config/mips/loongson.md
> ==
> =
> --- config/mips/loongson.md   (revision 228282)
> +++ config/mips/loongson.md   (working copy)
> @@ -852,58 +852,66 @@
>"dsrl\t%0,%1,%2"
>[(set_attr "type" "fcvt")])
> 
> -(define_expand "reduc_uplus_"
> -  [(match_operand:VWH 0 "register_operand" "")
> -   (match_operand:VWH 1 "register_operand" "")]
> +(define_insn "vec_loongson_extract_lo_"
> +  [(set (match_operand: 0 "register_operand" "=r")
> +(vec_select:
> +  (match_operand:VWHB 1 "register_operand" "f")
> +  (parallel [(const_int 0)])))]
>"TARGET_HARD_FLOAT && TARGET_LOONGSON_VECTORS"
> -{
> -  mips_expand_vec_reduc (operands[0], operands[1], gen_add3);
> -  DONE;
> -})
> +  "mfc1\t%0,%1"
> +  [(set_attr "type" "mfc")])
> 
> -; ??? Given that we're not describing a widening reduction, we should
> -; not have separate optabs for signed and unsigned.
> -(define_expand "reduc_splus_"
> -  [(match_operand:VWHB 0 "register_operand" "")
> +(define_expand "reduc_plus_scal_"
> +  [(match_operand: 0 "register_operand" "")
> (match_operand:VWHB 1 "register_operand" "")]
>"TARGET_HARD_FLOAT && TARGET_LOONGSON_VECTORS"
>  {
> -  emit_insn (gen_reduc_uplus_(operands[0], operands[1]));
> +  rtx tmp = gen_reg_rtx (GET_MODE (operands[1]));
> +  mips_expand_vec_reduc (tmp, operands[1], gen_add3);
> +  emit_insn (gen_vec_loongson_extract_lo_ (operands[0], tmp));
>DONE;
>  })
> 
> -(define_expand "reduc_smax_"
> -  [(match_operand:VWHB 0 "register_operand" "")
> +(define_expand "reduc_smax_scal_"
> +  [(match_operand: 0 "register_operand" "")
> (match_operand:VWHB 1 "register_operand" "")]
>"TARGET_HARD_FLOAT && TARGET_LOONGSON_VECTORS"
>  {
> -  mips_expand_vec_reduc (operands[0], operands[1], gen_smax3);
> +  rtx tmp = gen_reg_rtx (GET_MODE (operands[1]));
> +  mips_expand_vec_reduc (tmp, operands[1], gen_smax3);
> +  emit_insn (gen_vec_loongson_extract_lo_ (operands[0], tmp));
>DONE;
>  })
> 
> -(define_expand "reduc_smin_"
> -  [(match_operand:VWHB 0 "register_operand" "")
> +(define_expand "reduc_smin_scal_"
> +  [(match_operand: 0 "register_operand" "")
> (match_operand:VWHB 1 "register_operand" "")]
>"TARGET_HARD_FLOAT && TARGET_LOONGSON_VECTORS"
>  {
> -  mips_expand_vec_reduc (operands[0], operands[1], gen_smin3);
> +  rtx tmp = gen_reg_rtx (GET_MODE (operands[1]));
> +  mips_expand_vec_reduc (tmp, operands[1], gen_smin3);
> +  emit_insn (gen_vec_loongson_extract_lo_ (operands[0], tmp));
>DONE;
>  })
> 
> -(define_expand "reduc_umax_"
> -  [(match_operand:VB 0 "register_operand" "")
> +(define_expand "reduc_umax_scal_"
> +  [(match_operand: 0 "register_operand" "")
> (match_operand:VB 1 "register_operand" "")]
>"TARGET_HARD_FLOAT && TARGET_LOONGSON_VECTORS"
>  {
> -  mips_expand_vec_reduc (operands[0], operands[1],
> gen_umax3);
> +  rtx tmp = gen_reg_rtx (GET_MODE (operands[1]));
> +  mips_expand_vec_reduc (tmp, operands[1], gen_umax3);
> +  emit_insn (gen_vec_loongson_extract_lo_ (operands[0], tmp));
>DONE;
>  })
> 
> -(define_expand "reduc_umin_"
> -  [(match_operand:VB 0 "register_operand" "")
> +(define_expand "reduc_umin_scal_"
> +  [(match_operand: 0 "register_operand" "")
> (match_operand:VB 1 "register_operand" "")]
>"TARGET_HARD_FLOAT && TARGET_LOONGSON_VECTORS"
>  {
> -

RE: [PATCH, Mips] Compact branch/delay slot optimization.

2015-10-28 Thread Moore, Catherine



> -Original Message-
> From: Simon Dardis [mailto:simon.dar...@imgtec.com]
> Sent: Tuesday, October 06, 2015 10:00 AM
> To: Moore, Catherine; Matthew Fortune
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH, Mips] Compact branch/delay slot optimization.
> 
> Hello,
> 
> I'd like to resubmit the previous patch as it failed to check if the branch 
> inside
> the sequence had a compact form.
> 
> Thanks,
> Simon
> 
> gcc/
> * config/mips/mips.c: (mips_breakable_sequence_p): New function.
>   (mips_break_sequence): New function.
>   (mips_reorg_process_insns) Use them. Use compact branches in
> selected
>   situations.
> 
> gcc/testsuite/
> * gcc.target/mips/split-ds-sequence.c: Test for the above.

Hi Simon,
This patch looks okay with the exception of one stylistic change.
Please change all instances of :
+mips_breakable_sequence_p (rtx_insn * insn)
To:
+mips_breakable_sequence_p (rtx_insn *insn)
Okay, with those changes.
Thanks,
Catherine


> 
> Index: config/mips/mips.c
> ==
> =
> --- config/mips/mips.c(revision 228282)
> +++ config/mips/mips.c(working copy)
> @@ -16973,6 +16973,34 @@
>}
>  }
> 
> +/* A SEQUENCE is breakable iff the branch inside it has a compact form
> +   and the target has compact branches.  */
> +
> +static bool
> +mips_breakable_sequence_p (rtx_insn * insn)
> +{
> +  return (insn && GET_CODE (PATTERN (insn)) == SEQUENCE
> +   && TARGET_CB_MAYBE
> +   && get_attr_compact_form (SEQ_BEGIN (insn)) !=
> COMPACT_FORM_NEVER);
> +}
> +
> +/* Remove a SEQUENCE and replace it with the delay slot instruction
> +   followed by the branch and return the instruction in the delay slot.
> +   Return the first of the two new instructions.
> +   Subroutine of mips_reorg_process_insns.  */
> +
> +static rtx_insn *
> +mips_break_sequence (rtx_insn * insn)
> +{
> +  rtx_insn * before = PREV_INSN (insn);
> +  rtx_insn * branch = SEQ_BEGIN (insn);
> +  rtx_insn * ds = SEQ_END (insn);
> +  remove_insn (insn);
> +  add_insn_after (ds, before, NULL);
> +  add_insn_after (branch, ds, NULL);
> +  return ds;
> +}
> +
>  /* Go through the instruction stream and insert nops where necessary.
> Also delete any high-part relocations whose partnering low parts
> are now all dead.  See if the whole function can then be put into
> @@ -17065,6 +17093,68 @@
>   {
> if (GET_CODE (PATTERN (insn)) == SEQUENCE)
>   {
> +   rtx_insn * next_active = next_active_insn (insn);
> +   /* Undo delay slots to avoid bubbles if the next instruction can
> +  be placed in a forbidden slot or the cost of adding an
> +  explicit NOP in a forbidden slot is OK and if the SEQUENCE is
> +  safely breakable.  */
> +   if (TARGET_CB_MAYBE
> +   && mips_breakable_sequence_p (insn)
> +   && INSN_P (SEQ_BEGIN (insn))
> +   && INSN_P (SEQ_END (insn))
> +   && ((next_active
> +&& INSN_P (next_active)
> +&& GET_CODE (PATTERN (next_active)) != SEQUENCE
> +&& get_attr_can_delay (next_active) ==
> CAN_DELAY_YES)
> +   || !optimize_size))
> + {
> +   /* To hide a potential pipeline bubble, if we scan backwards
> +  from the current SEQUENCE and find that there is a load
> +  of a value that is used in the CTI and there are no
> +  dependencies between the CTI and instruction in the
> delay
> +  slot, break the sequence so the load delay is hidden.  */
> +   HARD_REG_SET uses;
> +   CLEAR_HARD_REG_SET (uses);
> +   note_uses ( (SEQ_BEGIN (insn)),
> record_hard_reg_uses,
> +  );
> +   HARD_REG_SET delay_sets;
> +   CLEAR_HARD_REG_SET (delay_sets);
> +   note_stores (PATTERN (SEQ_END (insn)),
> record_hard_reg_sets,
> +_sets);
> +
> +   rtx prev = prev_active_insn (insn);
> +   if (prev
> +   && GET_CODE (PATTERN (prev)) == SET
> +   && MEM_P (SET_SRC (PATTERN (prev
> + {
> +   HARD_REG_SET sets;
> +   CLEAR_HARD_REG_SET (sets);
> +   note_stores (PATTERN (prev), record_hard_reg_sets,
> +);
> +
&g

[Committed] Testsuite update for MIPS16

2015-10-28 Thread Moore, Catherine

I've now committed this patch to fix a couple of target-specific failures for 
MIP16 multilibs.

2015-10-28  Catherine Moore  

* gcc.target/mips/oddspreg-3.c: Disable for MIPS16.
* gcc.target/mips/oddspreg-6.c: Likewise.
* gcc.target/mips/oddspreg-1.c: Likewise.
* gcc.target/mips/oddspreg-2.c: Likewise.


Index: gcc.target/mips/oddspreg-6.c
===
--- gcc.target/mips/oddspreg-6.c(revision 229495)
+++ gcc.target/mips/oddspreg-6.c(working copy)
@@ -2,7 +2,7 @@
 /* { dg-skip-if "needs asm output" { *-*-* } { "-fno-fat-lto-objects" } { "" } 
} */
 /* { dg-options "-mabi=32 -mfpxx -mhard-float" } */

-void
+NOMIPS16 void
 foo ()
 {
   register float foo asm ("$f1"); /* { dg-error "isn't suitable for" } */
Index: gcc.target/mips/oddspreg-1.c
===
--- gcc.target/mips/oddspreg-1.c(revision 229495)
+++ gcc.target/mips/oddspreg-1.c(working copy)
@@ -5,7 +5,7 @@
 #error "Incorrect number of single-precision registers reported"
 #endif

-void
+NOMIPS16 void
 foo ()
 {
   register float foo asm ("$f1");
Index: gcc.target/mips/oddspreg-2.c
===
--- gcc.target/mips/oddspreg-2.c(revision 229495)
+++ gcc.target/mips/oddspreg-2.c(working copy)
@@ -2,7 +2,7 @@
 /* { dg-skip-if "needs asm output" { *-*-* } { "-fno-fat-lto-objects" } { "" } 
} */
 /* { dg-options "-mabi=32 -mno-odd-spreg -mhard-float" } */

-void
+NOMIPS16 void
 foo ()
 {
   register float foo asm ("$f1"); /* { dg-error "isn't suitable for" } */
Index: gcc.target/mips/oddspreg-3.c
===
--- gcc.target/mips/oddspreg-3.c(revision 229495)
+++ gcc.target/mips/oddspreg-3.c(working copy)
@@ -2,7 +2,7 @@
 /* { dg-skip-if "needs asm output" { *-*-* } { "-fno-fat-lto-objects" } { "" } 
} */
 /* { dg-options "-mabi=32 -mfp32 -march=loongson3a -mhard-float" } */

-void
+NOMIPS16 void
 foo ()
 {
   register float foo asm ("$f1"); /* { dg-error "isn't suitable for" } */

RE: [PATCH] Disable -mbranch-likely for -Os when targetting generic architecture

2015-10-22 Thread Moore, Catherine



> -Original Message-
> From: Robert Suchanek [mailto:robert.sucha...@imgtec.com]
> Sent: Friday, September 04, 2015 10:21 AM
> To: Matthew Fortune; Richard Sandiford
> Cc: Moore, Catherine; gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH] Disable -mbranch-likely for -Os when targetting generic
> architecture
> 
> Hi,
> 
> > Richard Sandiford <rdsandif...@googlemail.com> writes:
> > > Robert Suchanek <robert.sucha...@imgtec.com> writes:
> > > > The patch below disables generation of the branch likely
> > > > instructions for -
> > Os
> > > > but only for generic architecture.  The branch likely may result
> > > > in some code size reduction but the cost of running the code on R6
> > > > core is
> > significant.
> > >
> > > How about instead splitting PTF_AVOID_BRANCHLIKELY into
> > > PTF_AVOID_BRANCHLIKELY_SPEED and
> PTF_AVOID_BRANCHLIKELY_SIZE?
> > > We could have PTF_AVOID_BRANCHLIKELY_ALWAYS as an OR of the two.
> >
> > This sounds OK and is nicer.
> >
> > > Anything that does string ops on the architecture is suspicious :-)
> >
> > You can blame me for this.  I advocated the string comparison approach
> > as I had to do the same thing in gas IIRC for some feature and
> > couldn't think of anything better to suggest.
> 
> Here is an updated version that use the suggested method. Ok to apply?
> 
> Regards,
> Robert
> 
> gcc/
>   * config/mips/mips-cpus.def: Replace PTF_AVOID_BRANCHLIKELY
> with
>   PTF_AVOID_BRANCHLIKELY_ALWAYS for generic architecture and
> with
>   PTF_AVOID_BRANCHLIKELY_SPEED for others.
>   (mips2, mips3, mips4): Add PTF_AVOID_BRANCHLIKELY_SIZE to tune
> flags.
>   * config/mips/mips.c (mips_option_override): Enable the branch
> likely
>   depending on the tune flags and optimization level.
>   * config/mips/mips.h (PTF_AVOID_BRANCHLIKELY): Remove.
>   (PTF_AVOID_BRANCHLIKELY_SPEED): Define.
>   (PTF_AVOID_BRANCHLIKELY_SIZE): Likewise.
>   (PTF_AVOID_BRANCHLIKELY_ALWAYS): Likewise.
> ---
>  gcc/config/mips/mips-cpus.def | 56 +---
> ---
>  gcc/config/mips/mips.c|  6 +++--
>  gcc/config/mips/mips.h| 20 
>  3 files changed, 47 insertions(+), 35 deletions(-)
> 
> a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c index 0e0ecf2..f8775c4
> 100644
> --- a/gcc/config/mips/mips.c
> +++ b/gcc/config/mips/mips.c
> @@ -17916,8 +17916,10 @@ mips_option_override (void)
>if ((target_flags_explicit & MASK_BRANCHLIKELY) == 0)
>  {
>if (ISA_HAS_BRANCHLIKELY
> -   && (optimize_size
> -   || (mips_tune_info->tune_flags & PTF_AVOID_BRANCHLIKELY)
> == 0))
> +   && ((optimize_size && (mips_tune_info->tune_flags
> +  & PTF_AVOID_BRANCHLIKELY_SIZE) == 0)
> +|| (!optimize_size && (mips_tune_info->tune_flags
> +   & PTF_AVOID_BRANCHLIKELY_SPEED) ==
> 0)))
>   target_flags |= MASK_BRANCHLIKELY;
>else
>   target_flags &= ~MASK_BRANCHLIKELY;

Should this check be:
Index: mips.c
===
--- mips.c  (revision 229138)
+++ mips.c  (working copy)
@@ -17758,8 +17758,15 @@
   if ((target_flags_explicit & MASK_BRANCHLIKELY) == 0)
 {
   if (ISA_HAS_BRANCHLIKELY
- && (optimize_size
- || (mips_tune_info->tune_flags & PTF_AVOID_BRANCHLIKELY) == 0))
+ && ((optimize_size
+  && (mips_tune_info->tune_flags
+  & PTF_AVOID_BRANCHLIKELY_SIZE) == 0)
+ || (!optimize_size
+&& optimize > 0
+&& ((mips_tune_info->tune_flags
+ & PTF_AVOID_BRANCHLIKELY_SPEED) == 0))
+|| (mips_tune_info->tune_flags
+ & PTF_AVOID_BRANCHLIKELY_ALWAYS) == 0))
target_flags |= MASK_BRANCHLIKELY;
   else
target_flags &= ~MASK_BRANCHLIKELY;

Instead?  I don't see a use of PTF_AVOID_BRANCH_ALWAYS in your patch, but it 
seems like it should be checked.

RE: [PATCH, MIPS] Frame header optimization for MIPS O32 ABI

2015-10-07 Thread Moore, Catherine



> -Original Message-
> From: Steve Ellcey [mailto:sell...@imgtec.com]
> Sent: Tuesday, October 06, 2015 6:03 PM
> To: Moore, Catherine
> Cc: Matthew Fortune; GCC Patches
> Subject: RE: [PATCH, MIPS] Frame header optimization for MIPS O32 ABI
> 
> On Tue, 2015-10-06 at 12:02 +, Moore, Catherine wrote:
> 
> > > Moore, Catherine <catherine_mo...@mentor.com> writes:
> > > > The patch itself looks good, but the tests that you added need a little
> more
> > > work.
> 
> Here is a new patch for just the tests.  I added NOMIPS16 and the
> -mabi=32 flag as Matthew suggested and I also added -mno-abicalls.
> 
> Without the -mno-abicalls the MIPS linux compiler defaulted to
> -mabicalls and allocated 32 bytes without the optimization and the MIPS
> elf compiler defaulted to -mno-abicalls and allocated 24 bytes without
> the optimization.  This synchronizes them so they both allocate 24 bytes
> without the optimization and 8 bytes with it.  Everything should pass
> now, it passed for me using mips-mti-linux-gnu and mips-mti-elf.
> 
> Steve Ellcey
> sell...@imgtec.com
> 
> 
> 2015-10-06  Steve Ellcey  <sell...@imgtec.com>
> 
>   * gcc.target/mips/mips.exp (mips_option_groups): Add -mframe-
> header-opt
>   and -mno-frame-header-opt options.
>   * gcc.target/mips/frame-header-1.c: New file.
>   * gcc.target/mips/frame-header-2.c: New file.
>   * gcc.target/mips/frame-header-3.c: New file.
> 
> 
This looks good to go now.
Thanks,
Catherine

RE: [PATCH, MIPS] Frame header optimization for MIPS O32 ABI

2015-10-06 Thread Moore, Catherine



> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Tuesday, October 06, 2015 4:39 AM
> To: Moore, Catherine; Steve Ellcey
> Cc: GCC Patches
> Subject: RE: [PATCH, MIPS] Frame header optimization for MIPS O32 ABI
> 
> Moore, Catherine <catherine_mo...@mentor.com> writes:
> > The patch itself looks good, but the tests that you added need a little more
> work.
> >
> > I tested with the mips-sde-elf-lite configuration and I'm seeing
> > failures for many options.  The main failure mode seems to be that the
> > stack is incremented by 24 instead of 32.
> > I tried this change in frame-header-1.c and frame-header-3.c:
> >
> > /* { dg-final { scan-assembler-not "\taddiu\t\\\$sp,\\\$sp,-8" } }
> >
> > instead of:
> >
> > /* { dg-final { scan-assembler "\taddiu\t\\\$sp,\\\$sp,-32" }
> 
> I'd quite like to be specific about the frame layout we expect as the testcase
> is so simple that I think it should be predictable over time. Did you happen 
> to
> see a pattern to the failure? i.e. Could it be non-o32 ABIs? I'm not a fan of
> scan-assembler-nots in general as it is so easy to change exact output text
> and never match them anyway even if the offending instruction is
> generated.
There was not a pattern to the failure and I witnessed it for o32 ABIs.
> 
> > There are still errors in frame-header-2.c when compiling with -mips16
> > and -mabi=64 (this one uses a daddiu).
> > Also, the tests fail for -flto variants.
> 
> Let's just add NOMIPS16 (I think that is the macro) to the functions and lock
> the tests down to -mabi=32 which is the only ABI they are valid for anyway.
> 
> Matthew
> 
> > Would you please fix this up and resubmit?
> >
> > Thanks,
> > Catherine
> >
> > >
> > >
> > > diff --git a/gcc/testsuite/gcc.target/mips/frame-header-1.c
> > > b/gcc/testsuite/gcc.target/mips/frame-header-1.c
> > > new file mode 100644
> > > index 000..8495e0f
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/mips/frame-header-1.c
> > > @@ -0,0 +1,21 @@
> > > +/* Verify that we do not optimize away the frame header in foo when
> using
> > > +   -mno-frame-header-opt by checking the stack pointer increment done
> in
> > > +   that function.  Without the optimization foo should increment the
> stack
> > > +   by 32 bytes, with the optimization it would only be 8 bytes.  */
> > > +
> > > +/* { dg-do compile } */
> > > +/* { dg-options "-mno-frame-header-opt" } */
> > > +/* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
> > > +/* { dg-final { scan-assembler "\taddiu\t\\\$sp,\\\$sp,-32" } } */
> > > +
> > > +void __attribute__((noinline))
> > > +bar (int* a)
> > > +{
> > > +  *a = 1;
> > > +}
> > > +
> > > +void
> > > +foo (int a)
> > > +{
> > > +  bar ();
> > > +}
> > > diff --git a/gcc/testsuite/gcc.target/mips/frame-header-2.c
> > > b/gcc/testsuite/gcc.target/mips/frame-header-2.c
> > > new file mode 100644
> > > index 000..37ea2d1
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/mips/frame-header-2.c
> > > @@ -0,0 +1,21 @@
> > > +/* Verify that we do optimize away the frame header in foo when using
> > > +   -mframe-header-opt by checking the stack pointer increment done in
> > > +   that function.  Without the optimization foo should increment the
> > > +   stack by 32 bytes, with the optimization it would only be 8 bytes.
> > > +*/
> > > +
> > > +/* { dg-do compile } */
> > > +/* { dg-options "-mframe-header-opt" } */
> > > +/* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
> > > +/* { dg-final { scan-assembler "\taddiu\t\\\$sp,\\\$sp,-8" } } */
> > > +
> > > +void __attribute__((noinline))
> > > +bar (int* a)
> > > +{
> > > +  *a = 1;
> > > +}
> > > +
> > > +void
> > > +foo (int a)
> > > +{
> > > +  bar ();
> > > +}
> > > diff --git a/gcc/testsuite/gcc.target/mips/frame-header-3.c
> > > b/gcc/testsuite/gcc.target/mips/frame-header-3.c
> > > new file mode 100644
> > > index 000..1cb1547
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/mips/frame-header-3.c
> > > @@ -0,0 +1,22 @@
> > > +/* Ve

RE: [PATCH, MIPS] Frame header optimization for MIPS O32 ABI

2015-10-05 Thread Moore, Catherine



> -Original Message-
> From: Steve Ellcey [mailto:sell...@imgtec.com]
> Sent: Monday, October 05, 2015 1:16 PM
> To: Moore, Catherine
> Cc: Matthew Fortune; GCC Patches
> Subject: RE: [PATCH, MIPS] Frame header optimization for MIPS O32 ABI
> 
> On Mon, 2015-09-28 at 22:10 +, Moore, Catherine wrote:
> 
> > Hi Steve, I'm sorry for the delay in reviewing this patch.
> > Some changes have been committed upstream (see revision #227941) that
> > will require updates to this patch.
> > Please post the update for review.  Other comments are embedded.
> 
> OK, I have updated the comments based on your input and changed the
> code to compile with the ToT GCC after revision @227941.  Here is the new
> patch.
> 

HI Sreve,

The patch itself looks good, but the tests that you added need a little more 
work.

I tested with the mips-sde-elf-lite configuration and I'm seeing failures for 
many options.  The main failure mode seems to be that the stack is incremented 
by 24 instead of 32.
I tried this change in frame-header-1.c and frame-header-3.c:

/* { dg-final { scan-assembler-not "\taddiu\t\\\$sp,\\\$sp,-8" } } 

instead of:

/* { dg-final { scan-assembler "\taddiu\t\\\$sp,\\\$sp,-32" }

There are still errors in frame-header-2.c when compiling with -mips16 and 
-mabi=64 (this one uses a daddiu).
Also, the tests fail for -flto variants.

Would you please fix this up and resubmit?

Thanks,
Catherine

> 
> 
> diff --git a/gcc/testsuite/gcc.target/mips/frame-header-1.c
> b/gcc/testsuite/gcc.target/mips/frame-header-1.c
> new file mode 100644
> index 000..8495e0f
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/mips/frame-header-1.c
> @@ -0,0 +1,21 @@
> +/* Verify that we do not optimize away the frame header in foo when using
> +   -mno-frame-header-opt by checking the stack pointer increment done in
> +   that function.  Without the optimization foo should increment the stack
> +   by 32 bytes, with the optimization it would only be 8 bytes.  */
> +
> +/* { dg-do compile } */
> +/* { dg-options "-mno-frame-header-opt" } */
> +/* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
> +/* { dg-final { scan-assembler "\taddiu\t\\\$sp,\\\$sp,-32" } } */
> +
> +void __attribute__((noinline))
> +bar (int* a)
> +{
> +  *a = 1;
> +}
> +
> +void
> +foo (int a)
> +{
> +  bar ();
> +}
> diff --git a/gcc/testsuite/gcc.target/mips/frame-header-2.c
> b/gcc/testsuite/gcc.target/mips/frame-header-2.c
> new file mode 100644
> index 000..37ea2d1
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/mips/frame-header-2.c
> @@ -0,0 +1,21 @@
> +/* Verify that we do optimize away the frame header in foo when using
> +   -mframe-header-opt by checking the stack pointer increment done in
> +   that function.  Without the optimization foo should increment the
> +   stack by 32 bytes, with the optimization it would only be 8 bytes.
> +*/
> +
> +/* { dg-do compile } */
> +/* { dg-options "-mframe-header-opt" } */
> +/* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
> +/* { dg-final { scan-assembler "\taddiu\t\\\$sp,\\\$sp,-8" } } */
> +
> +void __attribute__((noinline))
> +bar (int* a)
> +{
> +  *a = 1;
> +}
> +
> +void
> +foo (int a)
> +{
> +  bar ();
> +}
> diff --git a/gcc/testsuite/gcc.target/mips/frame-header-3.c
> b/gcc/testsuite/gcc.target/mips/frame-header-3.c
> new file mode 100644
> index 000..1cb1547
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/mips/frame-header-3.c
> @@ -0,0 +1,22 @@
> +/* Verify that we do not optimize away the frame header in foo when using
> +   -mframe-header-opt but are calling a weak function that may be
> overridden
> +   by a different function that does need the frame header.  Without the
> +   optimization foo should increment the stack by 32 bytes, with the
> +   optimization it would only be 8 bytes.  */
> +
> +/* { dg-do compile } */
> +/* { dg-options "-mframe-header-opt" } */
> +/* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
> +/* { dg-final { scan-assembler "\taddiu\t\\\$sp,\\\$sp,-32" } } */
> +
> +void __attribute__((noinline, weak))
> +bar (int* a)
> +{
> +  *a = 1;
> +}
> +
> +void
> +foo (int a)
> +{
> +  bar ();
> +}
> diff --git a/gcc/testsuite/gcc.target/mips/mips.exp
> b/gcc/testsuite/gcc.target/mips/mips.exp
> index 42e7fff..0f2d6a2 100644
> --- a/gcc/testsuite/gcc.target/mips/mips.exp
> +++ b/gcc/testsuite/gcc.target/mips/mips.exp
> @@ -256,6 +256,7 @@ set mips_option_groups {
>  maddps "HAS_MADDPS"
>  lsa "(|!)HAS_LSA"
>  section_start "-Wl,--section-start=.*"
> +frame-header "-mframe-header-opt|-mno-frame-header-opt"
>  }
> 
>  for { set option 0 } { $option < 32 } { incr option } {
>

RE: [RFA] Compact EH Patch

2015-10-05 Thread Moore, Catherine


> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Subject: Re: [RFA] Compact EH Patch
> 

Richard, Thanks for the patch review.  
Matthew, Would you please take a look at the MIPS-specific pieces before I 
resubmit the patch?
There will be a small change to the data encoding for the MIPS-Linux toolchain 
to fix a problem that we found in the mabi=64 libraries.
 A follow-on patch to binutils will also be required.  I'll do an update to 
this patch, soon, including any changes for the MIPS backend.

Please see the embedded comments and a couple of questions.

Thanks,
Catherine

> > Index: libgcc/libgcc-std.ver.in
> >
> ==
> =
> > --- libgcc/libgcc-std.ver.in(revision 226409)
> > +++ libgcc/libgcc-std.ver.in(working copy)
> > @@ -1918,6 +1918,7 @@ GCC_4.6.0 {
> >__morestack_current_segment
> >__morestack_initial_sp
> >__splitstack_find
> > +  _Unwind_GetEhEncoding
> >  }
> >
> >  %inherit GCC_4.7.0 GCC_4.6.0
> > @@ -1938,3 +1939,8 @@ GCC_4.7.0 {
> >  %inherit GCC_4.8.0 GCC_4.7.0
> >  GCC_4.8.0 {
> >  }
> > +
> > +%inherit GCC_4.8.0 GCC_4.7.0
> > +GCC_4.8.0 {
> > +  __register_frame_info_header_bases
> > +}
> 
> You can't push new symbols into old versions.  These have to go into the
> version for the current gcc.

Yep, okay.  I'll fix these in the next version.
> 
> Likewise.
> 
> > +  if (data.type != CET_not_found)
> > +return data.type;
> > +
> > +  return CET_not_found;
> 
> Return data.type unconditionally.

OK.
> 
> > +++ libgcc/unwind-pe.h  (working copy)
> > @@ -44,6 +44,7 @@
> >  #define DW_EH_PE_udata2 0x02
> >  #define DW_EH_PE_udata4 0x03
> >  #define DW_EH_PE_udata8 0x04
> > +#define DW_EH_PE_udata1 0x05
> >  #define DW_EH_PE_sleb1280x09
> >  #define DW_EH_PE_sdata2 0x0A
> >  #define DW_EH_PE_sdata4 0x0B
> 
> If we're going to add udata1, we might as well add sdata1 for consistency.

OK.
> 
> > @@ -184,6 +187,7 @@ read_encoded_value_with_base (unsigned char
> encodi
> >union unaligned
> >  {
> >void *ptr;
> > +  unsigned u1 __attribute__ ((mode (QI)));
> >unsigned u2 __attribute__ ((mode (HI)));
> >unsigned u4 __attribute__ ((mode (SI)));
> >unsigned u8 __attribute__ ((mode (DI)));
> 
> This is silly.  Access to a single byte never requires alignment help from the
> compiler...

OK.
> 
> > +   case DW_EH_PE_udata1:
> > + result = u->u1;
> > + p += 1;
> > + break;
> 
> result = *p;
> 
> > +  read_encoded_value_with_base (DW_EH_PE_absptr |
> DW_EH_PE_udata4, 0,
> > +   hdr + 4, );
> 
> Err... that encoding type makes no sense: absptr is "pointer size".  Combining
> that with an explicit size, like udata4, means that udata4 wins.  So this is 
> the
> same as simply writing DW_EH_PE_udata4.
> 
> At which point you're loading a 4 byte unsigned quantity from an aligned
> address.  You might as well use *(uint32_t *)(hdr + 4).
> 

Ok, here as well.

> > +__register_frame_info_header_bases (const void *begin, struct object
> *ob,
> > +   void *tbase, void *dbase)
> > +{
> > +  /* Only register compact EH frame headers.  */
> > +  if (begin == NULL || *(const char *) begin != 2)
> > +return;
> 
> Check for no entries before registering?

That's reasonable.

> 
> > +extern char __GNU_EH_FRAME_HDR[] TARGET_ATTRIBUTE_WEAK;
> 
> Don't you have some guaranteed alignment for this table?
> That perhaps ought to be seen in either the type or an attribute.
> 

OK.
> +  if (op < 0x40)
> +  else if (op < 0x48)
> +  else if (op < 0x50)
> +  else if (op < 0x58)
> +  else if (op == 0x58)
> +  else if (op == 0x59)
> +  else if (op == 0x5a)
> +  else if (op == 0x5b)
> +  else if (op == 0x5c)
> +  else if (op == 0x5d)
> +  else if (op == 0x5e)
> +  else if (op == 0x5f)
> +  else if (op >= 0x60 && op < 0x6c)
> 
> Better as a switch statement surely, using the gcc case x ... y: extension.
OK.
> 
> > +static _Unwind_Reason_Code
> > +uw_frame_state_compact (struct _Unwind_Context *context,
> > +   _Unwind_FrameState *fs,
> > +   enum compact_entry_type entry_type,
> > +   struct compact_eh_bases *bases) {
> > +  const unsigned char *p;
> > +  unsigned int pr_index;
> > +  _Unwind_Ptr personality;
> > +  unsigned char buf[4];
> > +  _Unwind_Reason_Code rc;
> > +
> > +  p = bases->entry;
> > +  pr_index = *(p++);
> > +  switch (pr_index) {
> > +  case 0:
> > +  p = read_encoded_value (context, bases->eh_encoding, p,
> );
> > +  fs->personality = (_Unwind_Personality_Fn) personality;
> > +  break;
> > +  case 1:
> > +  fs->personality = __gnu_compact_pr1;
> > +  break;
> > +  case 2:
> > +  fs->personality = __gnu_compact_pr2;
> > +  break;
> > +  default:
> > +  fs->personality = NULL;
> > +  }
>

RE: [PATCH, MIPS] Frame header optimization for MIPS O32 ABI

2015-09-28 Thread Moore, Catherine



> -Original Message-
> From: Steve Ellcey [mailto:sell...@imgtec.com]
> Sent: Friday, September 11, 2015 2:06 PM
> To: Matthew Fortune
> Cc: GCC Patches; Moore, Catherine
> Subject: RE: [PATCH, MIPS] Frame header optimization for MIPS O32 ABI
> 
> On Fri, 2015-09-04 at 01:40 -0700, Matthew Fortune wrote:
> 
> > A few comments below. I found some of the comments a bit hard to parse
> but have
> > not attempted any rewording. I'd like Catherine to comment too as I have
> barely
> > any experience at the gimple level to know if this accounts for any
> necessary
> > subtleties.
> 
> Catherine said she would look at this next week but I have updated the
> patch in the mean time to address your comments and give Catherine a
> more up-to-date patch to look over.
> 

Hi Steve, I'm sorry for the delay in reviewing this patch. 
Some changes have been committed upstream (see revision #227941) that will 
require updates to this patch.
Please post the update for review.  Other comments are embedded.

> 
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 5712547..eea97de 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -420,6 +420,7 @@ microblaze*-*-*)
>  mips*-*-*)
>   cpu_type=mips
>   extra_headers="loongson.h"
> + extra_objs="frame-header-opt.o"
>   extra_options="${extra_options} g.opt fused-madd.opt mips/mips-
> tables.opt"
>   ;;
>  nds32*)
> diff --git a/gcc/config/mips/frame-header-opt.c b/gcc/config/mips/frame-
> header-opt.c
> index e69de29..5c4e93c 100644
> --- a/gcc/config/mips/frame-header-opt.c
> +++ b/gcc/config/mips/frame-header-opt.c
> @@ -0,0 +1,221 @@
> +/* Analyze functions to determine if calling functions need to allocate
> +   stack space (a frame header) for its called functions to write out their
> +   arguments on to the stack.  This optimization is only applicable to
> +   TARGET_OLDABI targets because calling functions on TARGET_NEWABI
> targets
> +   do not allocate any stack space for arguments (the called function does it
> +   if needed).
> +

Overall, I agree with Matthew regarding the comments being a little hard to 
parse.
How about:

/* Analyze functions to determine if callers need to allocate a frame header on 
the stack.  The frame header is used by callees to save its arguments.
   This optimization is specific to TARGET_OLDABI targets.  For TARGET_NEWABI 
targets, if a frame header is required, it is allocated by the callee.  */


> +
> +/* Look at all the functions this function calls and return true if none of
> +   them need the argument stack space that this function would normally
> +   allocate.  Return false if one or more functions does need this space
> +   or if we cannot determine that all called functions do not need the
> +   space.  */

/* Returns TRUE if the argument stack space allocated by function FN is used.
 Returns FALSE if the space is needed or if the need for the space cannot 
be determined.  */
> +
> +static bool
> +}
> +
> +/* This optimization scans all the functions in the compilation unit to find
> +   out which ones do not need the frame header that their caller normally
> +   allocates.  Then it does a second scan of all the functions to determine
> +   which functions can skip the allocation because none of the functions it
> +   calls need the frame header.  */
> +

  /* Scan each function to determine those that need its frame headers.  
Perform a second
   scan to determine if the allocation can be skipped because none of its 
callees require the frame header.  */
> +}
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index c0ec0fd..8152645 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -17940,6 +17941,18 @@ if @var{ra-address} is nonnull.
> 
>  The default is @option{-mno-mcount-ra-address}.
> 
> +@item -mframe-header-opt
> +@itemx -mno-frame-header-opt
> +@opindex mframe-header-opt
> +Enable (disable) frame header optimization in the o32 ABI.  When using
> +the o32 ABI, calling functions allocate 16 bytes on the stack in case
> +the called function needs to write out register arguments to memory so
> +that their address can be taken.  When enabled, this optimization will
> +cause the calling function to not allocate that space if it can determine
> +that none of its called functions use it.
> +
> +This optimization is off by default at all optimization levels.
> +
>  @end table
> 
>  @node MMIX Options

How about this instead:
Enable (disable) frame header optimization in the o32 ABI.  When using the o32
ABI, calling functions will allocate 16 bytes on the stack for the called 
function
to write out register arguments.  When enabled, this optimization will suppress 
the
allocation of the frame header if it can be determined that it is unused.

This optimization is off by default at all optimization levels.

Catherine

RE: [patch] libstdc++/65142 Check read() result in std::random_device.

2015-09-17 Thread Moore, Catherine



> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jonathan Wakely
> Sent: Thursday, September 17, 2015 5:28 PM
> To: Gerald Pfeifer
> Cc: libstd...@gcc.gnu.org; gcc-patches@gcc.gnu.org
> Subject: Re: [patch] libstdc++/65142 Check read() result in
> std::random_device.
> 
> On 17/09/15 22:21 +0200, Gerald Pfeifer wrote:
> >On Thu, 17 Sep 2015, Jonathan Wakely wrote:
> >>> Any comments on this version?
> >> Committed to trunk.
> >
> >Unfortunately this broke bootstrap on FreeBSD 10.1.
> >
> >/scratch/tmp/gerald/gcc-HEAD/libstdc++-v3/src/c++11/random.cc: In
> member function 'std::random_device::result_type
> std::random_device::_M_getval()':
> >/scratch/tmp/gerald/gcc-HEAD/libstdc++-v3/src/c++11/random.cc:144:22:
> >error: 'errno' was not declared in this scope
> >  else if (e != -1 || errno != EINTR)
> >  ^
> >/scratch/tmp/gerald/gcc-HEAD/libstdc++-v3/src/c++11/random.cc:144:31:
> >error: 'EINTR' was not declared in this scope
> >  else if (e != -1 || errno != EINTR)
> >   ^
> >Makefile:545: recipe for target 'random.lo' failed
> >
> >I probably won't be able to dig in deeper today, but figured this might
> >already send you on the right path?
> >
> >Actually...
> >
> >...how about he patch below?  Bootstraps on i386-unknown-freebsd10.1,
> >no regressions.
> 
> Sorry about that, I've committed your patch.
> 
> >Gerald
> >
> >
I'm still seeing errors for a build of the mips-sde-elf target with these 
patches.

Errors are:
/scratch/cmoore/virgin-upstream-elf-lite/src/gcc-trunk-5/libstdc++-v3/src/c++11/debug.cc:
 In function 'void {anonymous}::print_word({anonymous
}::PrintContext&, const char*, std::ptrdiff_t)':
/scratch/cmoore/virgin-upstream-elf-lite/src/gcc-trunk-5/libstdc++-v3/src/c++11/debug.cc:573:10:
 error: 'stderr' was not declared in this scop
e
  fprintf(stderr, "\n");
  ^
/scratch/cmoore/virgin-upstream-elf-lite/src/gcc-trunk-5/libstdc++-v3/src/c++11/debug.cc:573:22:
 error: 'fprintf' was not declared in this sco
pe
  fprintf(stderr, "\n");
  ^
/scratch/cmoore/virgin-upstream-elf-lite/src/gcc-trunk-5/libstdc++-v3/src/c++11/debug.cc:596:14:
 error: 'stderr' was not declared in this scop
e
  fprintf(stderr, "%s", spacing);
  ^
/scratch/cmoore/virgin-upstream-elf-lite/src/gcc-trunk-5/libstdc++-v3/src/c++11/debug.cc:596:35:
 error: 'fprintf' was not declared in this sco
pe
  fprintf(stderr, "%s", spacing);
   ^
/scratch/cmoore/virgin-upstream-elf-lite/src/gcc-trunk-5/libstdc++-v3/src/c++11/debug.cc:600:24:
 error: 'stderr' was not declared in this scope
  int written = fprintf(stderr, "%s", word);
^
/scratch/cmoore/virgin-upstream-elf-lite/src/gcc-trunk-5/libstdc++-v3/src/c++11/debug.cc:600:42:
 error: 'fprintf' was not declared in this scop
e
  int written = fprintf(stderr, "%s", word);
  ^

Thanks,
Catherine

RE: [patch] libstdc++/65142 Check read() result in std::random_device.

2015-09-17 Thread Moore, Catherine



> -Original Message-
> From: Jonathan Wakely [mailto:jwak...@redhat.com]
> Sent: Thursday, September 17, 2015 6:54 PM
> To: Moore, Catherine; fdum...@gcc.gnu.org
> Cc: Gerald Pfeifer; libstd...@gcc.gnu.org; gcc-patches@gcc.gnu.org
> Subject: Re: [patch] libstdc++/65142 Check read() result in
> std::random_device.
> 
> On 17/09/15 22:32 +, Moore, Catherine wrote:
> >
> >
> >> -Original Message-
> >> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> >> ow...@gcc.gnu.org] On Behalf Of Jonathan Wakely
> >> Sent: Thursday, September 17, 2015 5:28 PM
> >> To: Gerald Pfeifer
> >> Cc: libstd...@gcc.gnu.org; gcc-patches@gcc.gnu.org
> >> Subject: Re: [patch] libstdc++/65142 Check read() result in
> >> std::random_device.
> >>
> >> On 17/09/15 22:21 +0200, Gerald Pfeifer wrote:
> >> >On Thu, 17 Sep 2015, Jonathan Wakely wrote:
> >> >>> Any comments on this version?
> >> >> Committed to trunk.
> >> >
> >> >Unfortunately this broke bootstrap on FreeBSD 10.1.
> >> >
> >> >/scratch/tmp/gerald/gcc-HEAD/libstdc++-v3/src/c++11/random.cc: In
> >> member function 'std::random_device::result_type
> >> std::random_device::_M_getval()':
> >> >/scratch/tmp/gerald/gcc-HEAD/libstdc++-
> v3/src/c++11/random.cc:144:22:
> >> >error: 'errno' was not declared in this scope
> >> >  else if (e != -1 || errno != EINTR)
> >> >  ^
> >> >/scratch/tmp/gerald/gcc-HEAD/libstdc++-
> v3/src/c++11/random.cc:144:31:
> >> >error: 'EINTR' was not declared in this scope
> >> >  else if (e != -1 || errno != EINTR)
> >> >   ^
> >> >Makefile:545: recipe for target 'random.lo' failed
> >> >
> >> >I probably won't be able to dig in deeper today, but figured this
> >> >might already send you on the right path?
> >> >
> >> >Actually...
> >> >
> >> >...how about he patch below?  Bootstraps on
> >> >i386-unknown-freebsd10.1, no regressions.
> >>
> >> Sorry about that, I've committed your patch.
> >>
> >> >Gerald
> >> >
> >> >
> >I'm still seeing errors for a build of the mips-sde-elf target with these
> patches.
> >
> >Errors are:
> >/scratch/cmoore/virgin-upstream-elf-lite/src/gcc-trunk-5/libstdc++-v3/s
> >rc/c++11/debug.cc: In function 'void
> {anonymous}::print_word({anonymous
> >}::PrintContext&, const char*, std::ptrdiff_t)':
> >/scratch/cmoore/virgin-upstream-elf-lite/src/gcc-trunk-5/libstdc++-v3/s
> >rc/c++11/debug.cc:573:10: error: 'stderr' was not declared in this scop
> >e
> >  fprintf(stderr, "\n");
> >  ^
> >/scratch/cmoore/virgin-upstream-elf-lite/src/gcc-trunk-5/libstdc++-v3/s
> >rc/c++11/debug.cc:573:22: error: 'fprintf' was not declared in this sco
> >pe
> >  fprintf(stderr, "\n");
> >  ^
> >/scratch/cmoore/virgin-upstream-elf-lite/src/gcc-trunk-5/libstdc++-v3/s
> >rc/c++11/debug.cc:596:14: error: 'stderr' was not declared in this scop e
> >  fprintf(stderr, "%s", spacing);
> >  ^
> >/scratch/cmoore/virgin-upstream-elf-lite/src/gcc-trunk-5/libstdc++-v3/s
> >rc/c++11/debug.cc:596:35: error: 'fprintf' was not declared in this sco pe
> >  fprintf(stderr, "%s", spacing);
> >   ^
> >/scratch/cmoore/virgin-upstream-elf-lite/src/gcc-trunk-5/libstdc++-v3/s
> >rc/c++11/debug.cc:600:24: error: 'stderr' was not declared in this
> >scope
> >  int written = fprintf(stderr, "%s", word);
> >^
> >/scratch/cmoore/virgin-upstream-elf-lite/src/gcc-trunk-5/libstdc++-v3/s
> >rc/c++11/debug.cc:600:42: error: 'fprintf' was not declared in this
> >scop e
> >  int written = fprintf(stderr, "%s", word);
> 
> That's a different problem, due to https://gcc.gnu.org/r227885
> 
> François, could you take a look please?
> 

I've now committed this patch to solve this problem (pre-approved by Jonathan).

2015-09-17  Catherine Moore  <c...@codesourcery.com>

* src/c++11/debug.cc: Include .


Index: src/c++11/debug.cc
===
--- src/c++11/debug.cc  (revision 227887)
+++ src/c++11/debug.cc  (working copy)
@@ -32,6 +32,7 @@
 #include 

 #include 
+#include 

 #include  // for std::min
 #include  // for _Hash_impl

RE: [RFA] Compact EH Patch

2015-09-14 Thread Moore, Catherine



> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Wednesday, September 09, 2015 7:46 PM
> To: Jason Merrill; Moore, Catherine; gcc-patches@gcc.gnu.org
> Cc: Matthew Fortune; Ian Lance Taylor
> Subject: Re: [RFA] Compact EH Patch
> 
> On 09/09/2015 01:35 PM, Jason Merrill wrote:
> > On 07/30/2015 04:14 PM, Moore, Catherine wrote:
> >> This patch implements a more compact format for exception handling
> data.
> >> Although I don't have recent numbers for the amount of compression
> >> achieved, an earlier measurement showed a 30% reduction in the size
> >> of EH data for
> >> libstdc++.
> >>
> >> A design document detailing the new format is available
> >> (https://github.com/MentorEmbedded/cxx-
> abi/blob/master/MIPSCompactEH.pdf).
> >>
> >> This implementation enables the new format for MIPS targets only, but
> >> the generic pieces to enable the new format for other architectures is in
> place.
> >
> > Hi, sorry for the slow response.
> >
> > I'm surprised that there was no mention of this design on the ABI
> > list, especially since you've decided to post the design document to its git
> repository.
> >
> > I'm skeptical about the explicit rejection of asynchronous
> > backtracing; this is an important capability for debug traces on
> > hosted systems, which is why the compiler flag is on by default in
> > many linux distributions.  The document mentions using libunwind
> > instead, but that wouldn't help, as libunwind relies on the same
> > unwind information.  So it seems to me that the objective in 1.2 of
> supporting both unhosted and Linux-hosted programs isn't sufficiently met.

The support of asynchronous unwinding was not a requirement for our customer 
and wasn't addressed in the design.
As Richard points out, it is certainly possible to extend the scheme to support 
it, although I don't think such support should be a requirement for acceptance 
of the patch.

> 
> Indeed.  Though that is certainly fixable.
> 
> Let us suppose for the moment that the note on page 17 becomes true --
> use some of the currently unused encoding space for push/pop of state, and
> advancing the pc, so that one can represent asynchronous data.
> 
> At that point what's present there in section 10.1 looks plausible for use on
> MIPS.  With appropriate scheduling barriers in the mips prologue, it would in
> all likelyhood only add a single byte to the unwind info.
> 
> For instance, suppose
> 
>0101 1011  akin to DW_CFA_remember_state
>0101   akin to DW_CFA_restore_state
>0111  uleb128  akin to DW_CFA_advance_loc, of uleb128 * CALIGN
>0111   akin to DW_CFA_advance_loc, of  * CALIGN
> 
> where CALIGN is 4 for mips32 and 2 for mips16/micromips.  This allows one to
> advance 15 insns with 1 byte, and 127 insns with 2 bytes.
> 
> For the first example in 10.2.1 is instructive, in that it would take 5 bytes 
> to
> encode: pc += 1*4, sp += 56, pc += 8*4, push {16-22,31}, finish.  Given that
> most functions that allocate a stack frame will do so in the first insn, and
> indeed cannot do anything useful in zero instructions, one could make that
> first pc adjustment implicit, reducing the size of the unwind to 4 bytes, 
> which
> does fit into your inline unwind info.
> 
> Anyway, the exact encodings of this are something for the mips maintainers,
> since it isn't applicable generically.
> 
> Of more interest to me is the rest of the proposal, particularly section 10.4.
>   I like that there's more locality to the unwind data than the current
> .gcc_except_table contents.  I like that there's less pointer chasing.
> 
> Looking at the contents of my desktop, the vast majority of binaries have no
> .gcc_except_table, or a trivially small amount.  But I do have 102 binaries 
> with
> a table larger than 64k, with a maximum size of 705k.  So I also like the
> potential size savings of 25-40%.
> 
> The spec in section 10.4 looks good.  I can't see any issues with it off-hand.
> 
> The spec in section 8.2 out to be extended to handle 64-bit offsets instead of
> 32-bit offsets, even if only by reserving version 3 for the purpose.  While
> MIPS may want to restrict the size of the elf object to 2GB, and that's the
> common case for most files on all systems, we cannot restrict the size on all
> systems.
> 
> Anyway, that's having read the referenced document only, and nothing yet
> of the code.  I'll try to get to that tomorrow.
>

RE: [PATCH] MIPS: If a test in the MIPS testsuite requires standard library support check the sysroot supports the required test options.

2015-08-25 Thread Moore, Catherine

 -Original Message-
 From: Andrew Bennett [mailto:andrew.benn...@imgtec.com]
 Sent: Tuesday, July 21, 2015 10:15 AM
 To: gcc-patches@gcc.gnu.org
 Cc: Matthew Fortune; Moore, Catherine
 Subject: [PATCH] MIPS: If a test in the MIPS testsuite requires standard
 library support check the sysroot supports the required test options.

 Hi,

 The recent changes to the MIPS GCC Linux sysroot
 (https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01014.html) have meant
 that the include directory is now not global and is provided only for each
 multi-lib configuration.  This means that for any test in the MIPS GCC
 Testsuite that requires standard library support we need to check if there is 
 a
 multi-lib support for the test options, otherwise it might fail to compile.

 This patch adds this support to the testsuite and mips.exp files.  Firstly any
 test that requires standard library support has the implicit option
 (REQUIRES_STDLIB) added to its dg-options.  Secondly in mips.exp a pre-
 processor check is performed to ensure that when expanding a testcase
 containing a #include stdlib.h using the current set of test options we do
 not get file not found errors.  If this happens we mark the testcase as
 unsupported.

 The patch has been tested on the mti/img elf/linux-gnu toolchains, and there
 have been no new regressions.

 The patch and ChangeLog are below.

 Ok to commit?

Yes.  This looks good.

RE: [PATCH] MIPS: Add the lo register to the clobber list in the madd-8.c and msub-8.c testcases

2015-08-24 Thread Moore, Catherine

HI Andrew,

 -Original Message-
 From: Andrew Bennett [mailto:andrew.benn...@imgtec.com]
 Sent: Tuesday, July 21, 2015 10:56 AM
 To: gcc-patches@gcc.gnu.org
 Cc: Matthew Fortune; Moore, Catherine
 Subject: [PATCH] MIPS: Add the lo register to the clobber list in the madd-8.c
 and msub-8.c testcases

 Hi,

 The lo register is not listed in the clobber list in the inline asm statement 
 for
 the madd-8.c and msub-8.c testcases.  This means that when building for the
 n64 ABI GCC is free to use the lo register instead of the stack when
 saving/restoring the clobbered registers.  Then then means that it decides to
 use the msub/madd instruction to perform the x - y * z operation rather
 than using mul; addu/subu which the test is looking for.

 The following patch therefore adds the lo register to the clobber list for the
 madd-8.c and msub-8.c testcases.  The patch has been tested on the mti/img
 elf/linux-gnu toolchains, and there have been no new regressions.

 The patch and ChangeLog are below.

 Ok to commit?

Yes, this looks OK.

RE: [PATCH, MIPS] Compact branch support for MIPS32R6/MIPS64R6

2015-08-21 Thread Moore, Catherine

Hi Matthew:

 -Original Message-
 From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
 Sent: Monday, August 17, 2015 6:47 PM
 To: Moore, Catherine; 'gcc-patches@gcc.gnu.org' (gcc-patches@gcc.gnu.org)
 Subject: RE: [PATCH, MIPS] Compact branch support for MIPS32R6/MIPS64R6
 

One comment on the updated patch:

 diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index
 27be317..d7d9586 100644
 --- a/gcc/doc/invoke.texi
 +++ b/gcc/doc/invoke.texi
 @@ -781,6 +781,7 @@ Objective-C and Objective-C++ Dialects}.
  -mgp32  -mgp64  -mfp32  -mfpxx  -mfp64  -mhard-float  -msoft-float @gol  -
 mno-float  -msingle-float  -mdouble-float @gol  -modd-spreg -mno-odd-
 spreg @gol
 +-mcompact-branches=@var{policy} @gol
  -mabs=@var{mode}  -mnan=@var{encoding} @gol  -mdsp  -mno-dsp  -
 mdspr2  -mno-dspr2 @gol  -mmcu -mmno-mcu @gol @@ -17387,6 +17388,27
 @@ for the o32 ABI.  This is the default for processors that are known to
 support these registers.  When using the o32 FPXX ABI, @option{-mno-odd-
 spreg}  is set by default.
 
 +@item -mcompact-branches=never
 +@itemx -mcompact-branches=optimal
 +@itemx -mcompact-branches=always
 +@opindex mcompact-branches=never
 +@opindex mcompact-branches=optimal
 +@opindex mcompact-branches=always
 +These options control which form of branches will be generated.  The
 +default is @option{-mcompact-branches=optimal}.
 +
 +The @option{-mcompact-branches=never} option

Change:
 ensures that no compact branch instructions are generated.
 +
To:
   ensures that compact branch instructions will never be generated.

 +The @option{-mcompact-branches=always} option 

Change:
 ensures that only compact branch instructions are used unless there is only a 
delay slot form of a branch.  

To:
   ensures that a compact branch instruction will be generated if available.  
If a compact branch instruction is not available, a delay slot form of the 
branch will be used instead.
  
 This option is supported from MIPS Release 6 onwards.

 +The @option{-mcompact-branches=optimal} option 

Change:
will use delay slot
 +branches if available in the current ISA and the delay slot filler
 +successfully fills a delay slot. Otherwise, a compact branch will be
 +used if available.
 +
To:
Will cause a delay slot branch to be used if one is available in the current 
ISA and the delay slot is successfully filled.
If the delay slot is not filled,  a compact branch will be chosen if one is 
available.

Thanks,
Catherine

RE: [RFA] Compact EH Patch

2015-08-14 Thread Moore, Catherine

Hi Jason,
Are you going to be able to review this patch sometime soon?
Thanks,
Catherine

 -Original Message-
 From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
 ow...@gcc.gnu.org] On Behalf Of Moore, Catherine
 Sent: Thursday, July 30, 2015 4:15 PM
 To: gcc-patches@gcc.gnu.org
 Cc: ja...@redhat.com; Matthew Fortune
 Subject: [RFA] Compact EH Patch

 This patch implements a more compact format for exception handling data.
 Although I don't have recent numbers for the amount of compression
 achieved, an earlier measurement showed a 30% reduction in the size of EH
 data for libstdc++.

 A design document detailing the new format is available
 (https://github.com/MentorEmbedded/cxx-
 abi/blob/master/MIPSCompactEH.pdf).

 This implementation enables the new format for MIPS targets only, but the
 generic pieces to enable the new format for other architectures is in place.
 I couldn't really think of a good way to split up the patch to make the review
 easier, but I am open to suggestions.
 I've successfully bootstrapped with the patch and completed testing across
 many of the MIPS targets and multilibs.
 I also ran a test series for the x86 without regressions.
 Thanks,
 Catherine

RE: [PATCH, MIPS] Compact branch support for MIPS32R6/MIPS64R6

2015-08-14 Thread Moore, Catherine

Hi Matthew,

 -Original Message-
 From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
 Sent: Wednesday, July 22, 2015 6:19 PM
 Subject: [PATCH, MIPS] Compact branch support for MIPS32R6/MIPS64R6

This patch looks really good.  I have a couple of questions and a couple of 
nits that need to be fixed up.

 A full range of 'compact' branch instructions were introduced to MIPS
 as part of Release 6. The compact term is used to identify the fact
 that these do not have a delay slot.

 So how does all this work in GCC?

 Compact branches are used based on a branch policy. The polices are:

 never: Only use delay slot branches
 optimal: Do whatever is best for the current architecture.  This will
  generally mean that delay slot branches will be used if the delay
  slot gets filled but otherwise a compact branch will be used. A
  special case here is that JAL and J will not be used in R6 code
  regardless of whether the delay slot could be filled.
 always: Never emit a delay slot form of a branch if a compact form exists.
 This policy cannot apply 100% as FP branches (and MSA branches when
 committed) only have delay slot forms.

 These user choices are combined with the features available in the chosen
 architecture and, in particular, the optimal form will get handled like
 'never' when there are no compact branches available and will get handled
 like 'always' when there are no delay slot branches available.

Why did you choose to make this a user-selectable option?  Why not always 
generated optimal?
I don't have a strong opinion about it, but the options seem to complicate 
things and I'm interested in your rationale.

 The most complicated aspect of this change is to the MIPS_CALL and
 MICROMIPS_J macros. These have been rewritten from scratch as a function
 that generates an instruction instead.  

Thank you for cleaning this up.  The new function is much easier to follow.

 diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
 index c3cd52d..c0f2884 100644
 --- a/gcc/config/mips/mips.c
 +++ b/gcc/config/mips/mips.c

 +/* Return the asm template for a call.  OPERANDS are the operands,
 TARGET_OPNO
 +   is the operand number of the target.  SIZE_OPNO is the operand number
 of
 +   the argument size operand that can optionally hold the call attributes.  
 If
 +   SIZE_OPNO is not -1 and the call is indirect, use the function symbol from
 +   the call attributes to attach a R_MIPS_JALR relocation to the call.
 +

Might as well mention LINK_P here as well.

 +   When generating GOT code without explicit relocation operators, all calls
 +   should use assembly macros.  Otherwise, all indirect calls should use jr
 +   or jalr; we will arrange to restore $gp afterwards if necessary.  
 Finally,
 +   we can only generate direct calls for -mabicalls by temporarily switching
 +   to non-PIC mode.
 +
 +   For microMIPS jal(r), we try to generate jal(r)s when a 16-bit
 +   instruction is in the delay slot of jal(r).
 +
 +   Where compact branches are available, we try to use them if the delay
 slot
 +   has a NOP (or equivalently delay slots were not enabled for the 
 instruction
 +   anyway).  */
 +
 +const char *
 +mips_output_jump (rtx *operands, int target_opno, int size_opno, bool
 link_p)
 +{
 @@ -13038,6 +13165,59 @@ mips_output_conditional_branch (rtx_insn
 *insn, rtx *operands,
return ;
  }

 +const char *
 +mips_output_equal_conditional_branch (rtx_insn* insn, rtx *operands,
 +   bool inverted_p)

This function needs a comment.

diff --git a/gcc/config/mips/mips.opt b/gcc/config/mips/mips.opt
index 348c6e0..84887d1 100644
--- a/gcc/config/mips/mips.opt
+++ b/gcc/config/mips/mips.opt
@@ -418,3 +418,20 @@ Driver
 mload-store-pairs
 Target Report Var(TARGET_LOAD_STORE_PAIRS) Init(1)
 Enable load/store bonding.
+
+mcompact-branches=
+Target RejectNegative JoinedOrMissing Var(mips_cb) Report 
Enum(mips_cb_setting) Init(MIPS_CB_OPTIMAL)
+Specify the compact branch usage policy
+
+Enum
+Name(mips_cb_setting) Type(enum mips_cb_setting)
+Policies available for use with -mcompact-branches=:
+
+EnumValue
+Enum(mips_cb_setting) String(never) Value(MIPS_CB_NEVER)
+
+EnumValue
+Enum(mips_cb_setting) String(optimal) Value(MIPS_CB_OPTIMAL)
+
+EnumValue
+Enum(mips_cb_setting) String(always) Value(MIPS_CB_ALWAYS)

These need to be documented in invoke.texi.

diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index 5bc562e..04fe6d0 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
 @@ -92,6 +92,23 @@ struct mips_cpu_info {
  /* True if we are generating position-independent VxWorks RTP code.  */
  #define TARGET_RTP_PIC (TARGET_VXWORKS_RTP  flag_pic)

 +/* Set based on a combination of compact branch policy and ISA support.
 */
 +#define TARGET_CB_NEVER (mips_cb == MIPS_CB_NEVER\
 +  || (mips_cb == MIPS_CB_OPTIMAL \
 +

RE: [PATCH][MIPS] Fix register renaming in the interrupt handlers

2015-08-14 Thread Moore, Catherine

 -Original Message-
 From: Robert Suchanek [mailto:robert.sucha...@imgtec.com]
 Sent: Friday, August 14, 2015 8:01 AM
 To: Mike Stump; Richard Sandiford
 Cc: Moore, Catherine; Matthew Fortune; gcc-patches@gcc.gnu.org
 Subject: RE: [PATCH][MIPS] Fix register renaming in the interrupt handlers

 Hi,

   You also need to do the same thing for
 TARGET_HARD_REGNO_SCRATCH_OK,
   to stop peephole2 from using unsaved registers as scratch registers.

   I should dig out my patches to clean up this interface.  It's just
   too brittle to have two macros that say what registers can be used
   after reload.

 Indeed. I naively thought that there would be a single place that needed an
 update and overlooked this hook.

Sorry for missing this as well.  

 gcc/
   * config/mips/mips-protos.h (mips_hard_regno_rename_ok): New
 prototype.
   * config/mips/mips.c (mips_hard_regno_rename_ok): New
 function.
   (mips_hard_regno_scratch_ok): Likewise.
   (TARGET_HARD_REGNO_SCRATCH_OK): Define macro.
   * config/mips/mips.h (HARD_REGNO_RENAME_OK): New.

 gcc/testsuite/
   * gcc.target/mips/interrupt_handler-bug-1.c: New test.
 ---

Based on the feedback from Richard and Mike, this looks OK now.
Thanks,
Catherine

RE: [PATCH][MIPS] Fix register renaming in the interrupt handlers

2015-08-13 Thread Moore, Catherine



 -Original Message-
 From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
 Sent: Thursday, August 13, 2015 7:20 AM
 To: Robert Suchanek; Moore, Catherine
 Cc: gcc-patches@gcc.gnu.org
 Subject: RE: [PATCH][MIPS] Fix register renaming in the interrupt handlers
 
 I'd like to give Catherine chance to review this, I notice a couple of 
 formatting
 nits in the test case:

Yes, this patch is OK with Matthew's suggested changes.
Thanks,
Catherine

 
 Robert Suchanek robert.sucha...@imgtec.com writes:
  a/gcc/testsuite/gcc.target/mips/interrupt_handler-bug-1.c
  b/gcc/testsuite/gcc.target/mips/interrupt_handler-bug-1.c
  new file mode 100644
  index 000..877d00c
  --- /dev/null
  +++ b/gcc/testsuite/gcc.target/mips/interrupt_handler-bug-1.c
  @@ -0,0 +1,12 @@
  +/* { dg-options -funroll-loops } */ int foo; int bar;
  +
  +void __attribute__ ((interrupt)) isr(void) {
 
 Newline for function name and whitespace before args
 
  +  if (!foo)
  +   {
 
 Double space indent for brace or remove them entirely as it is single
 statement.
 
  +  while (bar  0xFF30);
  +   }
  +}
  +/* { dg-final { scan-assembler-not \\\$8 } } */
 
 Thanks,
 Matthew

RE: [PATCH, MIPS, Ping] Inline memcpy for MipsR6

2015-08-01 Thread Moore, Catherine

 -Original Message-
 From: Simon Dardis [mailto:simon.dar...@imgtec.com]
 Sent: Wednesday, July 29, 2015 4:29 AM
 To: gcc-patches@gcc.gnu.org
 Cc: Moore, Catherine
 Subject: [PATCH, MIPS, Ping] Inline memcpy for MipsR6

  This patch enables inline memcpy for R6 which was previously disabled and
 adds support for expansion when source and destination are at least half-
 word aligned.

 https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00749.html

Hi Simon,

Two things need to be fixed up with this patch before committing.

1.  The new test inline-memcpy-2.c should not be run with -OS (like the other 
new tests that you submitted).

2.  Your patch is against older source than what is currently in the 
repository, causing this hunk not to apply cleanly:

@@ -8311,8 +8321,8 @@ bool
 mips_expand_block_move (rtx dest, rtx src, rtx length)
 {
   if (!ISA_HAS_LWL_LWR
-(MEM_ALIGN (src)  BITS_PER_WORD
-  || MEM_ALIGN (dest)  BITS_PER_WORD))
+   (MEM_ALIGN (src)  MIPS_MIN_MOVE_MEM_ALIGN
+ || MEM_ALIGN (dest)  MIPS_MIN_MOVE_MEM_ALIGN))
 return false;

   if (CONST_INT_P (length))

The correct patch should like this:

@@ -7780,8 +7790,9 @@
 bool
 mips_expand_block_move (rtx dest, rtx src, rtx length)
 {
-  /* Disable entirely for R6 initially.  */
-  if (!ISA_HAS_LWL_LWR)
+  if (!ISA_HAS_LWL_LWR
+   (MEM_ALIGN (src)  MIPS_MIN_MOVE_MEM_ALIGN
+ || MEM_ALIGN (dest)  MIPS_MIN_MOVE_MEM_ALIGN))
 return false;

   if (CONST_INT_P (length))

Okay with those changes.
Thanks,
Catherine

RE: [PATCH][MIPS] Scheduler fix for the 74k 24k.

2015-07-31 Thread Moore, Catherine

 -Original Message-
 From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
 ow...@gcc.gnu.org] On Behalf Of Simon Dardis
 Sent: Tuesday, July 21, 2015 6:39 AM
 To: gcc-patches@gcc.gnu.org
 Subject: [PATCH][MIPS] Scheduler fix for the 74k  24k.

 Hello,

 This patch fixes a bug with the 74k  24k schedulers.

 Back in 2006  (2ca4dfa486bd358c6e466328839977250d160393) a
 mips_store_data_bypass_p was added to the mips backend. Unfortunately
 it was defined in terms of !store_data_bypass_p, though it was correctly
 used for the sb1 processor pipeline descriptor at that time. Later during a
 code-cleanup in 2012 (e053750d33e14ca245e14e1c467709a9bf6c6282) the 24k
  74k bypasses were changed from the correct !store_data_bypass_p to
 !mips_store_data_bypass_p. This lead to those bypasses having inverted
 guard conditions.

 This patch brings mips_store_data_bypass_p into line with its comments and
 the comments of store_data_bypass_p. It also corrects the sb1's pipeline
 description.

 Thanks,
 Simon

 gcc/
   * config/mips/mips.c (mips_store_data_bypass_p): Bring code into
   line with comments.
   * config/mips/sb1.md: Update usage of mips_store_data_bypass_p.

This patch is OK.

RE: [PATCH, MIPS] Add -march=interaptiv

2015-07-17 Thread Moore, Catherine



 -Original Message-
 From: Robert Suchanek [mailto:robert.sucha...@imgtec.com]
 Sent: Thursday, July 16, 2015 10:17 AM
 Subject: [PATCH, MIPS] Add -march=interaptiv
 
 As in the title, the attached patch adds -march=interaptiv defined to 24kf2_1,
 mapped to -mips32r2 and -mdsp.
 
 OK to apply?
 
 
 gcc/
   * config/mips/mips-cpus.def (interaptiv): Define.
   * config/mips/mips-tables.opt: Regenerate.
   * config/mips/mips.h (MIPS_ISA_LEVEL_SPEC): Map -
 march=interaptiv to
   -mips32r2.
   (BASE_DRIVER_SELF_SPECS): Likewise but map to -mdsp.
   * doc/invoke.texi (-march=@var{arch}): Add interaptiv.
 ---

Yes, this looks OK.

RE: [PATCH, MIPS] Support new interrupt handler options

2015-07-14 Thread Moore, Catherine

 -Original Message-
 From: Robert Suchanek [mailto:robert.sucha...@imgtec.com]
 Sent: Tuesday, July 14, 2015 11:14 AM
 To: Moore, Catherine; Matthew Fortune; gcc-patches@gcc.gnu.org
 Subject: RE: [PATCH, MIPS] Support new interrupt handler options

 Hi Catherine,

  I'm getting build errors with the current TOT and your patch.

  The first errors that I encounter are:
  gcc/config/mips/mips.c:1355:1: warning: 'mips_int_mask
  mips_interrupt_mask(tree)' defined but not used [-Wunused-function]
  gcc/config/mips/mips.c:1392:1: warning: 'mips_shadow_set
  mips_use_shadow_register_set(tree)' defined but not used
  [-Wunused-function]

  Removing these two functions results in further errors that I have not
  investigated.
  Will you try applying and building your patch again?

 I have no explanation why this could happen.  My guess is that a part of the
 patch did not apply correctly.  Those functions are used in
 mips_compute_frame_info().

 I did notice and fixed warnings about unused variables/arguments.

I re-ran patch with the verbose option and found that it was silently 
discarding hunks (starting with #7) because it thought it was garbage.

  I have a couple of further comments on the existing patch, see below.

 Comments added.  Please have a look at the attached revised patch.
 Tested against r225768.

 Regards,
 Robert

 gcc/
   * config/mips/mips.c (mips_int_mask): New enum.
   (mips_shadow_set): Likewise.
   (int_mask): New variable.
   (use_shadow_register_set_p): Change type to enum
 mips_shadow_set.
   (machine_function): Add int_mask and use_shadow_register_set.
   (mips_attribute_table): Add attribute handlers for interrupt and
   use_shadow_register_set.
   (mips_interrupt_mask): New static function.
   (mips_handle_interrupt_attr): Likewise.
   (mips_handle_use_shadow_register_set_attr): Likewise.
   (mips_use_shadow_register_set): Change return type to enum
   mips_shadow_set.  Add argument handling for
 use_shadow_register_set
   attribute.
   (mips_interrupt_extra_called_saved_reg_p): Update the conditional
 to
   compare with mips_shadow_set enum.
   (mips_compute_frame_info): Add interrupt mask and
   use_shadow_register_set to per-function information structure.
   Add a stack slot for EPC unconditionally.
   (mips_expand_prologue): Compare use_shadow_register_set value
   with mips_shadow_set enum.  Save EPC always in K1, clobber only K1
 for
   masked interrupt register but in EIC mode use K0 and save Cause in
 K0.
   EPC saved and restored unconditionally.  Use PMODE_INSN macro
 when
   copying the stack pointer from the shadow register set.
   * config/mips/mips.h (SR_IM0): New define.
   * config/mips/mips.md (mips_rdpgpr): Rename to...
   (mips_rdpgpr_mode): ...this.  Use the Pmode iterator.
   * doc/extend.texi (Declaring Attributes of Functions): Document
   optional arguments for interrupt and use_shadow_register_set
   attributes.

 gcc/testsuite/
   * gcc.target/mips/interrupt_handler-4.c: New test.

This is now OK to commit.
Catherine

RE: [PATCH] MIPS: Correctly update the isa and arch_test_option_p variables after the arch dependency handling code in mips.exp

2015-07-14 Thread Moore, Catherine

 -Original Message-
 From: Andrew Bennett [mailto:andrew.benn...@imgtec.com]
 Sent: Tuesday, July 14, 2015 9:24 AM
 To: Richard Sandiford; Matthew Fortune
 Cc: gcc-patches@gcc.gnu.org; Moore, Catherine
 Subject: RE: [PATCH] MIPS: Correctly update the isa and arch_test_option_p
 variables after the arch dependency handling code in mips.exp

  Yeah, I agree that this doesn't really fit the model that well, but
  like you say, we're stretching the logic a bit :-).  When I wrote it,
  the architectures formed a nice tree in which moving to leaf nodes
  only added features.  So in the pre-r6 days:

  # Handle dependencies between the pre-arch options and the arch
 option.
  # This should mirror the arch and post-arch code below.
  if { !$arch_test_option_p } {

  increased the architecture from the --target_board default to match
  the features required by the test, whereas:

  # Handle dependencies between the arch option and the post-arch
 options.
  # This should mirror the arch and pre-arch code above.
  if { $arch_test_option_p } {

  turned off features from the --target_board default to match a lower
  architecture required by the test.  So in the pre-r6 days, all the
  code in the second block was turning something off when going to a
  lower architecture.  The blocks were mutually-exclusive and writing it
  this way reduced the number of redundant options.  (Admittedly you
  could argue that it's daft to worry about that given the kind of
  command lines you tend to get from the rest of mips.exp. :-))

  r6 is the first time we've had to turn something off when moving up.
  -mnan and -mabs are also the first options where old architectures
  support only A, higher revisions support A and B, and the newest
  revision supports only B.  I think I'd prefer to acknowledge that and
  have:

  # Handle dependencies between the arch option and the post-arch
 options.
  # This should mirror the arch and pre-arch code above.  For pre-r6
  # architectures this only needs to be done when we've moved down
  # to a lower architecture and might need to turn features off,
  # but moving up from pre-r6 to r6 can remove features too.
  if { $arch_test_option_p || ($orig_isa_rev  6  $isa_rev = 6) }
  {

  I think the existing r6-r5 case really is different: there we're
  forcing a -mnan option not because the architecture needs it but
  because the environment might.

 Hi,

 An updated patch and ChangeLog which reflects the comments is below.
 I have tested it on the mips-img-elf and mips-mti-elf toolchains with all the
 valid multilib configurations and there are no new regressions.

 Ok to commit?

Yes, this is OK.

 testsuite/
   * gcc.target/mips/mips.exp (mips-dg-options): Allow the post-arch
   code to be run when the pre-arch code increases the isa_rev to
   mips32r6 or greater.

RE: [PATCH, MIPS] Support interrupt handlers with hard-float

2015-07-13 Thread Moore, Catherine



 -Original Message-
 From: Robert Suchanek [mailto:robert.sucha...@imgtec.com]
 Sent: Wednesday, July 08, 2015 6:42 AM
 To: Matthew Fortune; Moore, Catherine; gcc-patches@gcc.gnu.org
 Subject: [PATCH, MIPS] Support interrupt handlers with hard-float
 
 Hi Matthew/Catherine,
 
 The attached patch removes the restriction to compile a TU with an ISR with -
 mhard-float. Instead of forcing -msoft-float, the coprocessor 1 is disabled in
 an ISR for -mhard-float.
 
 Ok to apply?

Yes, this one is OK.

 
 gcc/
   * config/mips/mips.c (mips_compute_frame_info): Allow -mhard-
 float in
   interrupt attribute.
   (mips_expand_prologue): Disable the floating point unit in an ISR for
   -mhard-float.
   * config/mips/mips.h (SR_COP1): New define.

RE: [PATCH, MIPS] Support new interrupt handler options

2015-07-13 Thread Moore, Catherine

 -Original Message-
 From: Robert Suchanek [mailto:robert.sucha...@imgtec.com]
 Sent: Wednesday, July 08, 2015 6:43 AM
 To: Matthew Fortune; Moore, Catherine; gcc-patches@gcc.gnu.org
 Subject: [PATCH, MIPS] Support new interrupt handler options

 Hi,

 This patch adds support for optional arguments for interrupt and
 use_shadow_register_set attributes.  The patch also fixes an ICE if both
 interrupt and use_shadow_register_set are enabled and compiled with -
 mips64r2 -mabi=64 discovered during testing of the attached test.

 The interrupt attribute accepts new arguments: eic and
 vector=[sw0|sw1|hw0|hw1|hw2|hw3|hw4|hw5].  The former is the
 default if no argument is given and the latter changes the behaviour of GCC
 and masks interrupts from sw0 up to and including the specified vector.  As
 part of this change, the EPC is now saved and restored unconditionally to
 recover the state in nested interrupts.  Only K1 register is clobbered for
 masked interrupts but for non-masked interrupts K0 is still used.

 The use_shadow_register_set attribute has a new option, intstack, to
 indicate that the shadow register set has a valid stack pointer.  With this
 option rdpgpr $sp, $sp will not be generated for an ISR.

 Tested with mips-img-elf, mips-img-linux-gnu and mips64el-linux-gnu cross
 compilers. Ok to apply?

 Regards,
 Robert

 2015-07-07  Matthew Fortune  matthew.fort...@imgtec.com
 Robert Suchanek  robert.sucha...@imgtec.com

 gcc/
   * config/mips/mips.c (mips_int_mask): New enum.
   (mips_shadow_set): Likewise.
   (int_mask): New variable.
   (use_shadow_register_set_p): Change type to enum
 mips_shadow_set.
   (machine_function): Add int_mask and use_shadow_register_set.
   (mips_attribute_table): Add attribute handlers for interrupt and
   use_shadow_register_set.
   (mips_interrupt_mask): New static function.
   (mips_handle_interrupt_attr): Likewise.
   (mips_handle_use_shadow_register_set_attr): Likewise.
   (mips_use_shadow_register_set): Change return type to enum
   mips_shadow_set.  Add argument handling for
 use_shadow_register_set
   attribute.
   (mips_interrupt_extra_called_saved_reg_p): Update the conditional
 to
   compare with mips_shadow_set enum.
   (mips_compute_frame_info): Add interrupt mask and
   use_shadow_register_set to per-function information structure.
   Add a stack slot for EPC unconditionally.
   (mips_expand_prologue): Compare use_shadow_register_set value
   with mips_shadow_set enum.  Save EPC always in K1, clobber only K1
 for
   masked interrupt register but in EIC mode use K0 and save Cause in
 K0.
   EPC saved and restored unconditionally.  Use PMODE_INSN macro
 when
   copying the stack pointer from the shadow register set.
   * config/mips/mips.h (SR_IM0): New define.
   * config/mips/mips.md (mips_rdpgpr): Rename to...
   (mips_rdpgpr_mode): ...this.  Use the Pmode iterator.
   * doc/extend.texi (Declaring Attributes of Functions): Document
   optional arguments for interrupt and use_shadow_register_set
   attributes.

 gcc/testsuite/
   * gcc.target/mips/interrupt_handler-4.c: New test.

Hi Robert,
I'm getting build errors with the current TOT and your patch.

The first errors that I encounter are:
gcc/config/mips/mips.c:1355:1: warning: 'mips_int_mask 
mips_interrupt_mask(tree)' defined but not used [-Wunused-function]
gcc/config/mips/mips.c:1392:1: warning: 'mips_shadow_set 
mips_use_shadow_register_set(tree)' defined but not used [-Wunused-function]

Removing these two functions results in further errors that I have not 
investigated.
Will you try applying and building your patch again?

I have a couple of further comments on the existing patch, see below.

Thanks,
Catherine

 diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c index
 ce21a0f..b6ad7db 100644
 --- a/gcc/config/mips/mips.c
 +++ b/gcc/config/mips/mips.c
 @@ -1325,13 +1359,62 @@ mips_interrupt_type_p (tree type)
return lookup_attribute (interrupt, TYPE_ATTRIBUTES (type)) != NULL;  }

 +static enum mips_int_mask
 +mips_interrupt_mask (tree type)

This function requires a comment.

 +static enum mips_shadow_set
 +mips_use_shadow_register_set (tree type)

Likewise.

  {
 @@ -1537,6 +1620,87 @@ mips_can_inline_p (tree caller, tree callee)
  return false;
return default_target_can_inline_p (caller, callee);  }
 +
 +static tree
 +mips_handle_interrupt_attr (tree *node, tree name, tree args,
 + int flags ATTRIBUTE_UNUSED, bool *no_add_attrs)
 {
Likewise.

 +
 +static tree
 +mips_handle_use_shadow_register_set_attr (tree *node, tree name, tree
 args,

And here as well.

RE: [PATCH, MIPS] Fix restoration of hi/lo in MIPS64R2 interrupt handlers

2015-07-13 Thread Moore, Catherine

 -Original Message-
 From: Robert Suchanek [mailto:robert.sucha...@imgtec.com]
 Sent: Wednesday, July 08, 2015 6:43 AM
 To: Moore, Catherine; Matthew Fortune; gcc-patches@gcc.gnu.org
 Subject: [PATCH, MIPS] Fix restoration of hi/lo in MIPS64R2 interrupt
 handlers

 Hi,

 The attached patch fixes an ICE (unrecognizable insn) when accumulators are
 used in interrupt handlers for MIPS64R2. There was just a typo in the
 function name.

 Ok to apply?

 gcc/
   * config/mips/mips.c (mips_emit_save_slot_move): Fix typo.

 gcc/testsuite/
   * gcc.target/mips/20150707.c: New test.

Hi Robert,
The patch is OK, but will you please name the test something other than the 
date?
Thanks,
Catherine

RE: [PATCH] MIPS: fix failing branch range checks for micromips

2015-07-08 Thread Moore, Catherine

 -Original Message-
 From: Andrew Bennett [mailto:andrew.benn...@imgtec.com]
 Sent: Wednesday, July 08, 2015 11:17 AM
 To: Moore, Catherine; gcc-patches@gcc.gnu.org
 Cc: Matthew Fortune
 Subject: RE: [PATCH] MIPS: fix failing branch range checks for micromips

   testsuite/
 * gcc.target/mips/branch-2.c: Change NOMIPS16 to
 NOCOMPRESSION.
 * gcc.target/mips/branch-3.c: Ditto
 * gcc.target/mips/branch-4.c: Ditto.
 * gcc.target/mips/branch-5.c: Ditto.
 * gcc.target/mips/branch-6.c: Ditto.
 * gcc.target/mips/branch-7.c: Ditto.
 * gcc.target/mips/branch-8.c: Ditto.
 * gcc.target/mips/branch-9.c: Ditto.
 * gcc.target/mips/branch-10.c: Ditto.
 * gcc.target/mips/branch-11.c: Ditto.
 * gcc.target/mips/branch-12.c: Ditto.
 * gcc.target/mips/branch-13.c: Ditto.

  These are OK, except for the splitting of the scan-assembler statements.

  Please change occurrences of:
   +/* { dg-final { scan-assembler
   +\tld\t\\\$1,%got_page\\(\[^)\]*\\)\\(\\\$3\\)\\n } } */
  to:
  +/* { dg-final { scan-assembler
  \tld\t\\\$1,%got_page\\(\[^)\]*\\)\\(\\\$3\\)\\n } } */

  before committing.

 I think this might be a problem with your email client, as these issues do not
 occur in my patch submission.

Yes, it would appear that way.  Sorry for the noise.

 * gcc.target/mips/branch-14.c: Ditto.
 * gcc.target/mips/branch-15.c: Ditto.

  The modifications for these two files need to be removed.   These are
  execution tests and the multilib that is used to link them is important.   
  If
  the libraries are not compatible with the NOCOMPRESSION attribute,
  then the link step will fail.  You could work around this problem by
  enabling interlinking, but I think the best approach is to leave these two
 tests alone.

 Firstly, I have committed a patch which does not include the branch-[14,15].c
 and umips-branch-[17,18].c changes (SVN 225540).  However, I am keen to
 get these changes committed purely so that we have an in-range micromips
 branch execution test (which none of the current tests provide).  I need to
 look at the mips.exp file in more detail, but I was wondering if you would be
 happy to keep these tests in, but downgrade them to assemble tests if the
 required multilib support does not exist?

How about adding the interlinking option to the umips-branch-[17,18].c tests 
instead?
Ie.  /* { dg-options (-mmicromips) -minterlink-compressed } */

RE: [PATCH] MIPS: Update stack-1.c testcase to match micromips jraddiusp instruction.

2015-07-07 Thread Moore, Catherine

 -Original Message-
 From: Andrew Bennett [mailto:andrew.benn...@imgtec.com]
 Sent: Tuesday, July 07, 2015 12:14 PM
 To: Moore, Catherine; Matthew Fortune; gcc-patches@gcc.gnu.org
 Subject: RE: [PATCH] MIPS: Update stack-1.c testcase to match micromips
 jraddiusp instruction.

   I'm not sure this is the right approach here. If we get a jraddiusp
   then the problem that the test is trying to cover can't possibly happen
 anyway.
   (The test is checking if a load and final stack adjustment are ever
   re-
  ordered
   from what I can see.)

   I'd just mark the test as NOCOMPRESSION instead of just NOMIPS16 and
   update the comment to say that it is avoiding SAVE, RESTORE and
   JRADDIUSP.

  Another approach would be to add the micromips testcase variant and
  skip the test if code-quality (ie. -O0).
  Catherine

 I agree with Matthew here.  The testcase already comments that it is
 preventing the use of the MIPS16 save and restore instructions, so it makes
 sense to prevent jraddiusp as well.

 The updated patch and ChangeLog is below.

 Ok to commit?

 testsuite/
   * gcc.target/mips/stack-1.c: Do not build the testcase for micromips.

Yes, this is OK.

RE: [PATCH] MIPS: fix failing branch range checks for micromips

2015-07-07 Thread Moore, Catherine

Hi Andrew,

 -Original Message-
 From: Andrew Bennett [mailto:andrew.benn...@imgtec.com]
 Sent: Tuesday, July 07, 2015 12:13 PM
 To: Moore, Catherine; gcc-patches@gcc.gnu.org
 Cc: Matthew Fortune
 Subject: RE: [PATCH] MIPS: fix failing branch range checks for micromips

 Ok to commit?

 testsuite/
   * gcc.target/mips/branch-2.c: Change NOMIPS16 to
 NOCOMPRESSION.
   * gcc.target/mips/branch-3.c: Ditto
   * gcc.target/mips/branch-4.c: Ditto.
   * gcc.target/mips/branch-5.c: Ditto.
   * gcc.target/mips/branch-6.c: Ditto.
   * gcc.target/mips/branch-7.c: Ditto.
   * gcc.target/mips/branch-8.c: Ditto.
   * gcc.target/mips/branch-9.c: Ditto.
   * gcc.target/mips/branch-10.c: Ditto.
   * gcc.target/mips/branch-11.c: Ditto.
   * gcc.target/mips/branch-12.c: Ditto.
   * gcc.target/mips/branch-13.c: Ditto.

These are OK, except for the splitting of the scan-assembler statements.

Please change occurrences of:
 +/* { dg-final { scan-assembler
 +\tld\t\\\$1,%got_page\\(\[^)\]*\\)\\(\\\$3\\)\\n } } */
to: 
+/* { dg-final { scan-assembler 
\tld\t\\\$1,%got_page\\(\[^)\]*\\)\\(\\\$3\\)\\n } } */

before committing.

   * gcc.target/mips/branch-14.c: Ditto.
   * gcc.target/mips/branch-15.c: Ditto.

The modifications for these two files need to be removed.   These are execution 
tests and the multilib that is used to link them is important.   If the 
libraries are not compatible with the NOCOMPRESSION attribute, then the link 
step will fail.  You could work around this problem by enabling interlinking, 
but I think the best approach is to leave these two tests alone.

   * gcc.target/mips/umips-branch-5.c: New file.
   * gcc.target/mips/umips-branch-6.c: New file.
   * gcc.target/mips/umips-branch-7.c: New file.
   * gcc.target/mips/umips-branch-8.c: New file.
   * gcc.target/mips/umips-branch-9.c: New file.
   * gcc.target/mips/umips-branch-10.c: New file.
   * gcc.target/mips/umips-branch-11.c: New file.
   * gcc.target/mips/umips-branch-12.c: New file.
   * gcc.target/mips/umips-branch-13.c: New file.
   * gcc.target/mips/umips-branch-14.c: New file.
   * gcc.target/mips/umips-branch-15.c: New file.
   * gcc.target/mips/umips-branch-16.c: New file.

Same comment as above on the scan-assembler statements.

   * gcc.target/mips/umips-branch-17.c: New file.
   * gcc.target/mips/umips-branch-18.c: New file.

These two tests suffer from the same problem as above.  They should be deleted 
altogether.

   * gcc.target/mips/branch-helper.h (OCCUPY_0x1): New define.
   (OCCUPY_0xfffc): New define.

This is okay.

Thanks,
Catherine

 diff --git a/gcc/testsuite/gcc.target/mips/branch-10.c
 b/gcc/testsuite/gcc.target/mips/branch-10.c
 index e2b1b5f..eb21c16 100644
 --- a/gcc/testsuite/gcc.target/mips/branch-10.c
 +++ b/gcc/testsuite/gcc.target/mips/branch-10.c
 @@ -4,7 +4,7 @@

  #include branch-helper.h

 -NOMIPS16 void
 +NOCOMPRESSION void
  foo (int (*bar) (void), int *x)
  {
*x = bar ();
 diff --git a/gcc/testsuite/gcc.target/mips/branch-11.c
 b/gcc/testsuite/gcc.target/mips/branch-11.c
 index 962eb1b..bd8e834 100644
 --- a/gcc/testsuite/gcc.target/mips/branch-11.c
 +++ b/gcc/testsuite/gcc.target/mips/branch-11.c
 @@ -8,7 +8,7 @@

  #include branch-helper.h

 -NOMIPS16 void
 +NOCOMPRESSION void
  foo (int (*bar) (void), int *x)
  {
*x = bar ();
 diff --git a/gcc/testsuite/gcc.target/mips/branch-12.c
 b/gcc/testsuite/gcc.target/mips/branch-12.c
 index 4aef160..4944634 100644
 --- a/gcc/testsuite/gcc.target/mips/branch-12.c
 +++ b/gcc/testsuite/gcc.target/mips/branch-12.c
 @@ -4,7 +4,7 @@

  #include branch-helper.h

 -NOMIPS16 void
 +NOCOMPRESSION void
  foo (int (*bar) (void), int *x)
  {
*x = bar ();
 diff --git a/gcc/testsuite/gcc.target/mips/branch-13.c
 b/gcc/testsuite/gcc.target/mips/branch-13.c
 index 8a6fb04..f5269b9 100644
 --- a/gcc/testsuite/gcc.target/mips/branch-13.c
 +++ b/gcc/testsuite/gcc.target/mips/branch-13.c
 @@ -8,7 +8,7 @@

  #include branch-helper.h

 -NOMIPS16 void
 +NOCOMPRESSION void
  foo (int (*bar) (void), int *x)
  {
*x = bar ();
 diff --git a/gcc/testsuite/gcc.target/mips/branch-14.c
 b/gcc/testsuite/gcc.target/mips/branch-14.c
 index 026417e..c2eecc3 100644
 --- a/gcc/testsuite/gcc.target/mips/branch-14.c
 +++ b/gcc/testsuite/gcc.target/mips/branch-14.c
 @@ -4,14 +4,14 @@
  #include branch-helper.h

  void __attribute__((noinline))
 -foo (volatile int *x)
 +NOCOMPRESSION foo (volatile int *x)
  {
if (__builtin_expect (*x == 0, 1))
  OCCUPY_0x1fff8;
  }

  int
 -main (void)
 +NOCOMPRESSION main (void)
  {
int x = 0;
int y = 1;
 diff --git a/gcc/testsuite/gcc.target/mips/branch-15.c
 b/gcc/testsuite/gcc.target/mips/branch-15.c
 index dee7a05..89e25f3 100644
 --- a/gcc/testsuite/gcc.target/mips/branch-15.c
 +++ b/gcc/testsuite/gcc.target/mips/branch-15.c
 @@ -4,14 +4,14 @@
  #include branch-helper.h

  void
 -foo

RE: [PATCH] MIPS: Fix the call-[1,5,6].c tests to allow the jrc instruction to be matched when testing with microMIPS

2015-07-07 Thread Moore, Catherine

 -Original Message-
 From: Andrew Bennett [mailto:andrew.benn...@imgtec.com]
 Sent: Tuesday, July 07, 2015 6:53 AM
 To: gcc-patches@gcc.gnu.org
 Cc: Moore, Catherine; Matthew Fortune
 Subject: [PATCH] MIPS: Fix the call-[1,5,6].c tests to allow the jrc 
 instruction
 to be matched when testing with microMIPS

 Hi,

 When building the call-[1,5,6].c tests for micromips the jrc rather than the 
 jr
 instruction is used to call the tail* functions.

 I have updated the test output to allow the jrc instruction to be matched.

 I have tested this on the mips-mti-elf target using mips32r2/{-mno-
 micromips/-mmicromips}
 test options and there are no new regressions.

 The patch and ChangeLog are below.

 Ok to commit?

 testsuite/
   * gcc.target/mips/call-1.c: Allow testcase to match the jrc instruction.
   * gcc.target/mips/call-5.c: Ditto.
   * gcc.target/mips/call-6.c: Ditto.

OK.

RE: [PATCH] MIPS: For micromips allow near-far-3.c test to use the jals instruction to call near_func

2015-07-06 Thread Moore, Catherine

 -Original Message-
 From: Andrew Bennett [mailto:andrew.benn...@imgtec.com]
 Sent: Monday, July 06, 2015 9:20 AM
 To: gcc-patches@gcc.gnu.org
 Cc: Matthew Fortune; Moore, Catherine
 Subject: [PATCH] MIPS: For micromips allow near-far-3.c test to use the jals
 instruction to call near_func

 Hi,

 The near-far-3.c test is failing for micromips because it is expecting the 
 call to
 near_func to be performed by a jal instruction, but for micromips this is done
 by a jals instruction.

 I have updated the expected test output to deal with this case.  I have tested
 this on the mips-mti-elf target using mips32r2/{-mno-micromips/-
 mmicromips}
 test options and there are no new regressions.

 The patch and ChangeLog are below.

 Ok to commit?

 testsuite/
   * gcc.target/mips/near-far-3.c: Allow the call to near_func to use
 the jals instruction.

OK.

RE: [PATCH] MIPS: Do not generate micromips code for the no-smartmips-lwxs.c testcase

2015-07-06 Thread Moore, Catherine

 -Original Message-
 From: Andrew Bennett [mailto:andrew.benn...@imgtec.com]
 Sent: Monday, July 06, 2015 9:34 AM
 To: gcc-patches@gcc.gnu.org
 Cc: Matthew Fortune; Moore, Catherine
 Subject: [PATCH] MIPS: Do not generate micromips code for the no-
 smartmips-lwxs.c testcase

 Hi,

 The LWXS instruction is part of the micromips ISA which means it is valid to
 generate it for the no-smartmips-lwxs.c testcase.  I have updated the dg-
 options for the test to ensure that it does not generate micromips code.

 I have tested this on the mips-mti-elf target using mips32r2/{-mno-
 micromips/-mmicromips} test options and there are no new regressions.

 The patch and ChangeLog are below.

 Ok to commit?

 Many thanks,

 Andrew

 testsuite/
   * gcc.target/mips/no-smartmips-lwxs.c: Add -mno-micromips to dg-
 options.

 diff --git a/gcc/testsuite/gcc.target/mips/no-smartmips-lwxs.c
 b/gcc/testsuite/gcc.target/mips/no-smartmips-lwxs.c
 index ecf856e..6701a1c 100644
 --- a/gcc/testsuite/gcc.target/mips/no-smartmips-lwxs.c
 +++ b/gcc/testsuite/gcc.target/mips/no-smartmips-lwxs.c
 @@ -1,5 +1,5 @@
  /* { dg-do compile } */
 -/* { dg-options -mno-smartmips } */
 +/* { dg-options -mno-smartmips -mno-micromips } */

  NOMIPS16 int scaled_indexed_word_load (int a[], int b)  {

Hi Andrew,

Instead of adding the -mno-micromips option to dg-options, please change the 
MIPS16 attribute to NOCOMPRESSION.

Index: gcc.target/mips/no-smartmips-lwxs.c
===
--- gcc.target/mips/no-smartmips-lwxs.c (revision 452061)
+++ gcc.target/mips/no-smartmips-lwxs.c (working copy)
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options -mno-smartmips } */

-NOMIPS16 int scaled_indexed_word_load (int a[], int b)
+NOCOMPRESSION int scaled_indexed_word_load (int a[], int b)
 {
   return a[b];
 }

OK with that change.
Catherine

RE: [PATCH] MIPS: fix failing branch range checks for micromips

2015-07-06 Thread Moore, Catherine

Hi Andrew,

 -Original Message-
 From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
 ow...@gcc.gnu.org] On Behalf Of Andrew Bennett
 Sent: Friday, July 03, 2015 7:50 PM
 Subject: [PATCH] MIPS: fix failing branch range checks for micromips
 
 diff --git a/gcc/testsuite/gcc.target/mips/branch-10.c
 b/gcc/testsuite/gcc.target/mips/branch-10.c
 index e2b1b5f..00569b0 100644
 --- a/gcc/testsuite/gcc.target/mips/branch-10.c
 +++ b/gcc/testsuite/gcc.target/mips/branch-10.c
 @@ -1,4 +1,4 @@
 -/* { dg-options -mshared -mabi=n32 } */
 +/* { dg-options -mshared -mabi=n32 -mno-micromips } */
  /* { dg-final { scan-assembler-not (\\\$28|%gp_rel|%got) } } */
  /* { dg-final { scan-assembler-not \tjr\t\\\$1\n } } */
 

Like the other patch, the -mno-micromips should be removed from dg-options and 
NOCOMPRESS used in place of NOMIPS16.
This comment applies to all of the branch-*.c tests.

 
 diff --git a/gcc/testsuite/gcc.target/mips/branch-helper.h
 b/gcc/testsuite/gcc.target/mips/branch-helper.h
 index 85399be..bc4a31f 100644
 --- a/gcc/testsuite/gcc.target/mips/branch-helper.h
 +++ b/gcc/testsuite/gcc.target/mips/branch-helper.h
 @@ -33,5 +33,23 @@
 D2 (nop) \n\t \
 D1 (nop))
 
 +/* Emit something that is 0xfffc bytes long, which is the largest
 +   permissible range for micromips forward branches when branches

s/micromips/microMIPS/

 +   have delay slots.  */
 +#define OCCUPY_0xfffc \
 +  asm (D13 (nop32) \n\t \
 +   D12 (nop32) \n\t \
 +   D11 (nop32) \n\t \
 +   D10 (nop32) \n\t \
 +   D9 (nop32) \n\t \
 +   D8 (nop32) \n\t \
 +   D7 (nop32) \n\t \
 +   D6 (nop32) \n\t \
 +   D5 (nop32) \n\t \
 +   D4 (nop32) \n\t \
 +   D3 (nop32) \n\t \
 +   D2 (nop32) \n\t \
 +   D1 (nop32) \n\t \
 +   D0 (nop32))
  /* Likewise emit something that is 0x1fffc bytes long.  */  #define
 OCCUPY_0x1fffc do { asm (nop); OCCUPY_0x1fff8; } while (0)

diff --git
 a/gcc/testsuite/gcc.target/mips/branch-umips-10.c
 b/gcc/testsuite/gcc.target/mips/branch-umips-10.c

I see that you are naming these tests after the original branch-number tests 
that they were derived from.
I think it would be better to keep all of the microMIPS tests named umips-???.  
  I don't think preserving the original number is important.

Thanks,
Catherine

RE: [PATCH] MIPS: Update stack-1.c testcase to match micromips jraddiusp instruction.

2015-07-06 Thread Moore, Catherine

 -Original Message-
 From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
 Sent: Monday, July 06, 2015 11:00 AM
 To: Andrew Bennett; gcc-patches@gcc.gnu.org
 Cc: Moore, Catherine
 Subject: RE: [PATCH] MIPS: Update stack-1.c testcase to match micromips
 jraddiusp instruction.

 Andrew Bennett andrew.benn...@imgtec.com writes:
  The stack-1.c testcase fails when being compiled for micromips with
  the
  -O0 optimization level.  The reason is the testcase is expecting the
  following sequence at the end of the function:

 addiu   $sp,$sp,16
 jrc $31

  But for micromips it generates the following:

 jraddiusp   16

  As the failure only happens at one optimization level I have decided
  to just change the expected output rather than creating a separate
  micromips testcase.

 I'm not sure this is the right approach here. If we get a jraddiusp then the
 problem that the test is trying to cover can't possibly happen anyway.
 (The test is checking if a load and final stack adjustment are ever re-ordered
 from what I can see.)

 I'd just mark the test as NOCOMPRESSION instead of just NOMIPS16 and
 update the comment to say that it is avoiding SAVE, RESTORE and
 JRADDIUSP.

Another approach would be to add the micromips testcase variant and skip the 
test if code-quality (ie. -O0).
Catherine

RE: [Patch, MIPS] Enable fp-contract on MIPS and update -mfused-madd

2015-06-29 Thread Moore, Catherine

 -Original Message-
 From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
 Sent: Monday, June 29, 2015 3:07 PM
 To: Maciej W. Rozycki; Steve Ellcey; Moore, Catherine; Richard Biener
 Cc: Richard Sandiford; Richard Sandiford; Myers, Joseph; gcc-
 patc...@gcc.gnu.org
 Subject: RE: [Patch, MIPS] Enable fp-contract on MIPS and update -mfused-
 madd

 Maciej W. Rozycki ma...@linux-mips.org writes:
  Richard, please have a look at my question below in a reference to
  your previous statement.

  On Thu, 18 Jun 2015, Steve Ellcey wrote:

   OK, I checked in the prequel patch and here is a new copy of the
   original patch based off of that (and with no HONOR_NAN checks in
   the fma/madd instructions).

   OK for checkin?

   Please see below for my notes.

   2015-06-18  Steve Ellcey  sell...@imgtec.com

 * config.gcc (mips*-*-*): Add fused-madd.opt.

   Please use angle brackets as per
  https://www.gnu.org/prep/standards/html_node/Indicating-the-Part-
 Chan
  ged.html,
  i.e.:

  * config.gcc mips*-*-*: Add fused-madd.opt.

  There's no function or similar entity involved here and `mips*-*-*' is
  a case value like with the C language's `switch' statement where you'd
  use angle brackets too to refer to individual cases.

 (*nmsub4mode_fastmath)  Update condition.

   Extraneous space here.

   The change looks good to me otherwise.

Maciej

 If nobody can identify any further functional issues with this patch then I'd
 like to get this committed and pursue enhancements as a second round.
 Catherine, would you be happy for this to be committed on that basis?

Yes, this is fine with me.

RE: [RFC]: Remove Mem/address type assumption in combiner

2015-05-12 Thread Moore, Catherine

 -Original Message-
 From: Steve Ellcey [mailto:sell...@imgtec.com]
 Sent: Tuesday, May 12, 2015 12:51 PM
 To: Kumar, Venkataramanan
 Cc: Segher Boessenkool; Jeff Law (l...@redhat.com); gcc-
 patc...@gcc.gnu.org; maxim.kuvyr...@linaro.org; Matthew Fortune;
 Moore, Catherine
 Subject: RE: [RFC]: Remove Mem/address type assumption in combiner

 On Tue, 2015-05-12 at 05:21 +, Kumar, Venkataramanan wrote:
  Hi Steve,

  Yes this is expected.  As Segher pointed out, we need to change .md
  patterns in target to be based on shifts instead of mults.

  Regards,
  Venkat.

 Here is my patch to change this.  I tested it with the mips-mti-linux-gnu and
 mips-mti-elf targets and it fixed the MIPS specific tests that were scanning
 for an lsa instruction and it also had no regressions.

 Since the lsa instruction was the only one using the 'y' operand code and my
 change got rid of the only use of it, I removed it as part of this patch.

 Matthew or Catherine is this OK to checkin?

 2015-05-12  Steve Ellcey  sell...@imgtec.com

   * config/mips/mips.c (mips_print_operand): Remove 'y' operand
 code.
   * config/mips/mips.md (GPR:dlsa): Rewrite with shift operator.
   * config/mips/predicates.md (const_immlsa_operand): Remove log
 call.

This is OK.
Catherine

RE: [patch, MIPS, testsuite] Fix gcc.target/mips/branch-1.c

2015-05-11 Thread Moore, Catherine

 -Original Message-
 From: Steve Ellcey [mailto:sell...@imgtec.com]
 Sent: Monday, May 11, 2015 12:02 PM
 To: gcc-patches@gcc.gnu.org
 Cc: matthew.fort...@imgtec.com; Moore, Catherine
 Subject: [patch, MIPS, testsuite] Fix gcc.target/mips/branch-1.c

 The test gcc.target/mips/branch-1.c has started failing because it is trying 
 to
 verify that each of 4 functions generates and 'andi' instruction and only
 finding 2 of them.  With a recent change (fixing PR 65150) GCC determined
 that the f1 and f2 functions generate identical code and that the f3 and f4
 functions generate identical code and so it replaced f1 with a tail call to 
 f2 and
 f3 with a tail call to f4.  Thus only 2 'andi' instructions show up and the 
 test
 fails.

 There is an existing bug report (PR 65534) about whether or not this is a good
 optimization but I would like to fix this test so that that optimization can 
 not
 happen since that is not what this test is intended to check for.  My solution
 is to pass different arguments to bar() in each function so the code in each
 function is unique.

 Tested with mips-mti-linux-gnu, OK to checkin?

 Steve Ellcey
 sell...@imgtec.com

 2015-05-11  Steve Ellcey  sell...@mips.com

   * gcc.target/mips/branch-1.c: Pass argument to bar().

This is OK.
Catherine

RE: [PATCH v4][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

2015-04-29 Thread Moore, Catherine

 -Original Message-
 From: Petar Jovanovic [mailto:petar.jovano...@rt-rk.com]
 Sent: Friday, April 24, 2015 10:51 AM
 Subject: [PATCH v4][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

 gcc/ChangeLog:

 2015-04-21  Petar Jovanovic  petar.jovano...@rt-rk.com

   * config/mips/mips.h (CRT_CALL_STATIC_FUNCTION): Fix the macro
 to use
   la/jalr instead of jal.

 gcc/testsuite/ChangeLog:

 2015-04-21  Petar Jovanovic  petar.jovano...@rt-rk.com

   * gcc.target/mips/call-from-init.c: New test.
   * gcc.target/mips/mips.exp: Add section_start to

Thank you, Petar.  I have now committed this patch.
Catherine

RE: [Patch, MIPS] Change mips4 default processor to r10K

2015-04-29 Thread Moore, Catherine

 -Original Message-
 From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
 Sent: Tuesday, April 28, 2015 2:38 PM
 
 Steve Ellcey  sell...@imgtec.com writes:
 
  2015-04-28  Steve Ellcey  sell...@imgtec.com
 
  * config/mips/mips-cpus.def: (mips4): Change default processor
  from PROCESSOR_R8000 to PROCESSOR_R1.
 
 Ok with me. I'd like Catherine to have the chance to raise any concerns
 though.

This change is OK with me, as well.
Catherine

RE: [PATCH][MIPS] Enable load-load/store-store bonding

2015-04-20 Thread Moore, Catherine

 -Original Message-
 From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
 Sent: Monday, April 20, 2015 3:10 PM
 To: Sameera Deshpande; Moore, Catherine
 Cc: Richard Sandiford; gcc-patches@gcc.gnu.org; echri...@gmail.com
 Subject: RE: [PATCH][MIPS] Enable load-load/store-store bonding

 Sameera Deshpande sameera.deshpa...@imgtec.com writes:
  Gentle reminder!

 Thanks Sameera. Just a couple of comments inline below and a question for
 Catherine at the end.

  - Thanks and regards,
 Sameera D.

  On Monday 30 March 2015 04:58 PM, sameera wrote:
   Hi!

   Sorry for delay in sending this patch for review.
   Please find attached updated patch.

   In P5600, 2 consecutive loads/stores of same type which access
   contiguous memory locations are bonded together by instruction issue
   unit to dispatch single load/store instruction which accesses both
  locations. This allows 2X improvement in memory intensive code. This
  optimization can be performed for LH, SH, LW, SW, LWC, SWC, LDC, SDC
  instructions.

   This patch adds peephole2 patterns to identify such loads/stores,
   and put them in parallel, so that the scheduler will not split it -
  thereby guaranteeing h/w level load/store bonding.

   The patch is tested with dejagnu for correctness, and tested on
  hardware for performance.
   Ok for trunk?

   Changelog:
   gcc/
* config/mips/mips.md (JOIN_MODE): New mode iterator.
(join2_load_StoreJOIN_MODE:mode): New pattern.
(join2_loadhi): Likewise.
(define_peehole2): Add peephole2 patterns to join 2
   HI/SI/SF/DF-
  mode
load-load and store-stores.
* config/mips/mips.opt (mload-store-pairs): New option.
(TARGET_LOAD_STORE_PAIRS): New macro.
*config/mips/mips.h (ENABLE_LD_ST_PAIRS): Likewise.
*config/mips/mips-protos.h (mips_load_store_bonding_p): New
  prototype.
*config/mips/mips.c(mips_load_store_bonding_p): New function.

 I don't know if this has been corrupted by mail clients but a single space 
 after
 '*' and a space before '('.

 diff --git a/gcc/config/mips/mips-protos.h
 b/gcc/config/mips/mips-protos.h index b48e04f..244eb8d 100644
 --- a/gcc/config/mips/mips-protos.h
 +++ b/gcc/config/mips/mips-protos.h
 @@ -360,6 +360,7 @@ extern bool mips_epilogue_uses (unsigned int);
 extern void mips_final_prescan_insn (rtx_insn *, rtx *, int);  extern
 int mips_trampoline_code_size (void);  extern void
 mips_function_profiler (FILE *);
 +extern bool mips_load_store_bonding_p (rtx *, machine_mode, bool);

  typedef rtx (*mulsidi3_gen_fn) (rtx, rtx, rtx);  #ifdef RTX_CODE diff
 --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c index
 1733457..85f0591 100644
 --- a/gcc/config/mips/mips.c
 +++ b/gcc/config/mips/mips.c
 @@ -18241,6 +18241,64 @@ umips_load_store_pair_p_1 (bool load_p,
 bool swap_p,
return true;
  }

 +bool
 +mips_load_store_bonding_p (rtx *operands, enum machine_mode
 mode, bool
 +load_p)

 Remove enum from machine_mode.

 +{
 +  rtx reg1, reg2, mem1, mem2, base1, base2;
 +  enum reg_class rc1, rc2;
 +  HOST_WIDE_INT offset1, offset2;
 +
 +  if (load_p)
 +{
 +  reg1 = operands[0];
 +  reg2 = operands[2];
 +  mem1 = operands[1];
 +  mem2 = operands[3];
 +}
 +  else
 +{
 +  reg1 = operands[1];
 +  reg2 = operands[3];
 +  mem1 = operands[0];
 +  mem2 = operands[2];
 +}
 +
 +  if (mips_address_insns (XEXP (mem1, 0), mode, false) == 0
 +  || mips_address_insns (XEXP (mem2, 0), mode, false) == 0)
 +return false;
 +
 +  mips_split_plus (XEXP (mem1, 0), base1, offset1);  mips_split_plus
 + (XEXP (mem2, 0), base2, offset2);
 +
 +  /* Base regs do not match.  */
 +  if (!REG_P (base1) || !rtx_equal_p (base1, base2))
 +return false;
 +
 +  /* Either of the loads is clobbering base register.  */
 +  if (load_p
 +   (REGNO (reg1) == REGNO (base1)
 +  || (REGNO (reg2) == REGNO (base1
 +return false;

 Can you add a comment saying that this case does not get bonded by any
 known hardware even though it could be valid to bond them if it is the
 second load that clobbers the base.

 +  /* Loading in same registers.  */
 +  if (load_p
 +   REGNO (reg1) == REGNO (reg2))
 +return false;
 +
 +  /* The loads/stores are not of same type.  */
 +  rc1 = REGNO_REG_CLASS (REGNO (reg1));
 +  rc2 = REGNO_REG_CLASS (REGNO (reg2));  if (rc1 != rc2
 +   !reg_class_subset_p (rc1, rc2)
 +   !reg_class_subset_p (rc2, rc1))
 +return false;
 +
 +  if (abs (offset1 - offset2) != GET_MODE_SIZE (mode))
 +return false;
 +
 +  return true;
 +}
 +
  /* OPERANDS describes the operands to a pair of SETs, in the order
 dest1, src1, dest2, src2.  Return true if the operands can be used
 in an LWP or SWP instruction; LOAD_P says which.  */ diff --git
 a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h index
 ec69ed5..1bd0dae 100644
 --- a/gcc/config/mips/mips.h
 +++ b/gcc/config/mips/mips.h
 @@ -3147,3

RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

2015-04-17 Thread Moore, Catherine

 -Original Message-
 From: Petar Jovanovic [mailto:petar.jovano...@rt-rk.com]
 Sent: Friday, April 17, 2015 2:23 PM
 To: Petar Jovanovic
 Cc: Maciej W. Rozycki; Matthew Fortune; gcc-patches@gcc.gnu.org; Moore,
 Catherine
 Subject: RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

 Resending the previous message in a plain text format.

   Original Message 
  Subject: RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro
  Date: Thursday, April 16, 2015 10:38 PM CEST
  From: Moore, Catherine catherine_mo...@mentor.com
  To: Maciej W. Rozycki ma...@linux-mips.org, Petar
  Jovanovicpetar.jovano...@rt-rk.com
  CC: 'Matthew Fortune' matthew.fort...@imgtec.com,
  gcc-patches@gcc.gnu.orggcc-patches@gcc.gnu.org
  References:
  003e01d04179$ccc38bc0$664aa340$@rt-
 rk.com6D39441BF12EF246A7ABCE6654

 b0235320fca...@lemail01.le.imgtec.org000201d04723$f69b1350$e3d13
 9f0$
  @rt-rk.com000501d07865$e26f2830$a74d7890$@rt-rk.com
  Hi Petar,
  It looks like I answered a little too quickly the first time around. I'm 
  sorry.
  In any case, Maciej is correct. I think a link-time test should do it.
  Thanks,
  Catherine

   You'd need `objdump' for doing that and there is no ready-to-use
   solution within the GCC test suite available, you'd have to cook
   something up yourself, perhaps starting with `[find_binutils_prog
 objdump]'.

   Another solution might be using an auxiliary linker script (`-Wl,-T,...'
   or maybe just an implicit linker script will do; see the LD manual
   for
   details) to place the sections the jump is made between apart
   manually at addresses appropriate for JAL to fail. They span does
   not have to be large -- when placed correctly, even `JAL .' can jump
   to the wrong place, which is what LD is supposed to catch as a
   relocation error -- so a test executable successfully linked with
   your correction in place won't be large, it doesn't have to take more than
 2 virtual pages.

   The downside of the latter solution are possible portability issues
   with the linker script. You won't have to run your executable AFAICT
   from glibc BZ
   #17601 as you'll get a link error if a jump target is out of range.
   So you could make it a mere link test, no need to run it.

   Maciej

  Hi Maciej, Catherine,

  This issue will not trigger a linker error (I believe it treats the  symbol
 referred by the relocation as a local symbol). This is a follow  up to GLIBC 
 BZ
 #17601, the problem is seen only at runtime. So, I think  this brings back the
 need to run the test. I can look into separating  sections with -Wl,-T.. (that
 may also require extending  mips_option_groups in mips/mips.exp), if
 running executable is OK.

Hi Petar,  
Running the executable is fine, but didn't you say that your test case takes 
hours to execute?
If so, that's not acceptable.  Is it possible to construct a test case that 
will run more quickly?
Thanks,
Catherine

RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

2015-04-16 Thread Moore, Catherine

 -Original Message-
 From: Maciej W. Rozycki [mailto:ma...@linux-mips.org]
 Sent: Thursday, April 16, 2015 2:23 PM
 To: Petar Jovanovic
 Cc: Moore, Catherine; 'Matthew Fortune'; gcc-patches@gcc.gnu.org
 Subject: RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

 On Thu, 16 Apr 2015, Petar Jovanovic wrote:

   There isn't any need to execute a large testcase.  Instead, try
   adding a
  short version of your test to the directory gcc/testsuite/gcc.target/mips.
   There are examples of other tests there they check for specific
   assembler
  sequences by using scan-assembler.   See umips-swp-1.c (and others) for a
  specific example of how to do this.
   Let me know if you need additional help.
   Thanks,
   Catherine

  Hi Catherine,

  Sorry for late response, I have missed to follow up on this.
  IIUC, scan-assembler will scan assembly file generated from a test file.
  This particular change will - on the other hand - modify crtend.o and
  thus init section. Is there a 'scan-assembler' functionality over a
  final linked executable, as that would actually test the change?

Hi Petar,
It looks like I answered a little too quickly the first time around.  I'm sorry.
In any case, Maciej is correct.  I think a link-time test should do it.
Thanks,
Catherine

  You'd need `objdump' for doing that and there is no ready-to-use solution
 within the GCC test suite available, you'd have to cook something up
 yourself, perhaps starting with `[find_binutils_prog objdump]'.

  Another solution might be using an auxiliary linker script (`-Wl,-T,...'
 or maybe just an implicit linker script will do; see the LD manual for
 details) to place the sections the jump is made between apart manually at
 addresses appropriate for JAL to fail.  They span does not have to be large --
 when placed correctly, even `JAL .' can jump to the wrong place, which is
 what LD is supposed to catch as a relocation error -- so a test executable
 successfully linked with your correction in place won't be large, it doesn't
 have to take more than 2 virtual pages.

  The downside of the latter solution are possible portability issues with the
 linker script.  You won't have to run your executable AFAICT from glibc BZ
 #17601 as you'll get a link error if a jump target is out of range.  So you 
 could
 make it a mere link test, no need to run it.

   Maciej

RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

2015-02-12 Thread Moore, Catherine

 -Original Message-
 From: Petar Jovanovic [mailto:petar.jovano...@rt-rk.com]
 Sent: Thursday, February 12, 2015 7:28 PM
 Subject: RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

 -Original Message-
 From: Moore, Catherine [mailto:catherine_mo...@mentor.com]
 Sent: Friday, February 6, 2015 4:13 PM
 To: Matthew Fortune; Petar Jovanovic; gcc-patches@gcc.gnu.org; 'Maciej W.
 Rozycki'
 Subject: RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

  Petar,  would you please add your testcase to the gcc testsuite and repost
 the patch.

 Hi Catherine,

 Sure, I can repost the patch and add the test case I used.
 My concern - and I would appreciate feedback from you and others on it - is
 that the test I originally used to report [1] the problem creates a large
 executable (380 MB).

 The test also takes time to execute. Obviously, I can make it slightly more
 complex and make execute time short. Another path is to introduce and use
 options such as Wl,-Ttext-segment to make its size smaller. Any other
 ideas?

Hi Petar,

There isn't any need to execute a large testcase.  Instead, try adding a short 
version of your test to the directory gcc/testsuite/gcc.target/mips.
There are examples of other tests there they check for specific assembler 
sequences by using scan-assembler.   See umips-swp-1.c (and others) for a 
specific example of how to do this.
Let me know if you need additional help.
Thanks,
Catherine

RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

2015-02-06 Thread Moore, Catherine

 -Original Message-
 From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
 Sent: Thursday, February 05, 2015 3:52 PM
 Subject: RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

 I've put your patch inline below and switched to plain text. I suspect your
 post was bounced by gcc-patches.

 I'm OK with this change but I'd like Catherine to comment before committing.
 It seems a shame to duplicate the block of code but it is probably just as 
 ugly
 to define a macro for the la/dla instruction.

The patch itself is OK, although I agree with other's comments about the 
unfortunate duplication of code.
Petar,  would you please add your testcase to the gcc testsuite and repost the 
patch.
Thanks,
Catherine

 For future reference, it is best not to include changelog content in a patch
 but instead just paste into the email. Also the ChangeLog you need for this
 change is gcc/ChangeLog (as confusing as that may be at first).

 Thanks,
 Matthew

  From: Petar Jovanovic [mailto:petar.jovano...@rt-rk.com]
  Sent: 05 February 2015 19:28
  To: gcc-patches@gcc.gnu.org; 'Maciej W. Rozycki'; Matthew Fortune
  Subject: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

  v2:
  - add ChangeLog entry
  - use DLA instead of LA for n64

  PTAL. Thanks.

  Regards,
  Petar

 ---
  ChangeLog  |  5 +
  gcc/config/mips/mips.h | 23 +++
  2 files changed, 24 insertions(+), 4 deletions(-)

 diff --git a/ChangeLog b/ChangeLog
 index 5c61c66..3a15f4a 100644
 --- a/ChangeLog
 +++ b/ChangeLog
 @@ -1,3 +1,8 @@
 +2015-02-05  Petar Jovanovic  petar.jovano...@rt-rk.com
 +
 + * config/mips/mips.h (CRT_CALL_STATIC_FUNCTION): Fix the macro
 to use
 + la/jalr instead of jal.
 +
  2015-02-02  Janis Johnson  janis.marie.john...@gmail.com

   * MAINTAINERS (Various Maintainers: testsuite): Remove myself.
 diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h index
 ec69ed5..4bd83f5 100644
 --- a/gcc/config/mips/mips.h
 +++ b/gcc/config/mips/mips.h
 @@ -3034,11 +3034,11 @@ while (0)
   nop\n\
  1:   .cpload $31\n\
   .set reorder\n\
 - jal  USER_LABEL_PREFIX #FUNC \n\
 + la $25,  USER_LABEL_PREFIX #FUNC \n\
 + jalr $25\n\
   .set pop\n\
TEXT_SECTION_ASM_OP);
 -#elif ((defined _ABIN32  _MIPS_SIM == _ABIN32) \
 -   || (defined _ABI64  _MIPS_SIM == _ABI64))
 +#elif (defined _ABIN32  _MIPS_SIM == _ABIN32)
  #define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC)   \
 asm (SECTION_OP \n\
   .set push\n\
 @@ -3048,7 +3048,22 @@ while (0)
   nop\n\
  1:   .set reorder\n\
   .cpsetup $31, $2, 1b\n\
 - jal  USER_LABEL_PREFIX #FUNC \n\
 + la $25,  USER_LABEL_PREFIX #FUNC \n\
 + jalr $25\n\
 + .set pop\n\
 +  TEXT_SECTION_ASM_OP);
 +#elif (defined _ABI64  _MIPS_SIM == _ABI64)
 +#define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC)   \
 +   asm (SECTION_OP \n\
 + .set push\n\
 + .set nomips16\n\
 + .set noreorder\n\
 + bal 1f\n\
 + nop\n\
 +1:   .set reorder\n\
 + .cpsetup $31, $2, 1b\n\
 + dla $25,  USER_LABEL_PREFIX #FUNC \n\
 + jalr $25\n\
   .set pop\n\
TEXT_SECTION_ASM_OP);
  #endif
 --
 1.8.2.1

RE: [PATCH,WWWDOCS] MIPS changes for GCC 5.0

2015-02-06 Thread Moore, Catherine



 -Original Message-
 From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
 Sent: Thursday, February 05, 2015 5:24 AM
 To: Moore, Catherine
 Cc: 'gcc-patches@gcc.gnu.org' (gcc-patches@gcc.gnu.org)
 Subject: RE: [PATCH,WWWDOCS] MIPS changes for GCC 5.0
 
 Moore, Catherine catherine_mo...@mentor.com writes:
  Hi Matthew,
 
  I made a few edits.  I removed the markup in the process, so that will
  need to be added back.
  See the text at the end.
 
 Thanks Catherine. Good call to remove the markup while reviewing. I've
 done one more pass on this to have the same phrasing used where similar
 points are being made. I also added a comment about link compatibility for
 FP64.  Updated text is at the end.
 
This looks good now.

 
   -Original Message-
   From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
   Sent: Wednesday, February 04, 2015 11:46 AM
   To: Moore, Catherine
   Cc: 'gcc-patches@gcc.gnu.org' (gcc-patches@gcc.gnu.org)
   Subject: [PATCH,WWWDOCS] MIPS changes for GCC 5.0
  
   Hi Catherine,
  
   I've made a first pass at writing up the MIPS changes for GCC 5.0.
   Could you take a read and see what needs some more work?
  
   Thanks,
   Matthew
  
   Index: htdocs/gcc-5/changes.html
  
 ==
   =
   RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
   retrieving revision 1.77
   diff -r1.77 changes.html
   562a563,614
h3 id=mipsMIPS/h3
  ul
liMIPS Releases 3 and 5 are now directly supported using
code-
   mips32r3,
-mips64r3, -mips32r5 and -mips64r5/code instead of relying
on the
   Release
2 options./li
liSupport for the Imagination P5600 processor has been added
  using
code-march=p5600/code.
/li
liSupport for the Cavium Networks Octeon3 processor has been
added
   using
code-march=octeon3/code./li
liMIPS Release 6 is now supported using code-mips32r6 and
-
   mips64r6
/code.
liThe previous o32 64-bit floating-point register support
has
  been
obsoleted and removed.  This was previously enabled using
code-
   mfp64
/code which has been re-purposed for the new ABI extensions
   described
below./li
liNew o32 ABI extensions have been added to enable software
to
   transition
away from the original layout of double-precision
floating-point
  registers.
ul
  liThe first of these extensions is o32 FPXX which places
  restrictions
  on code-generation to never access the upper 32-bits of
double-
   precision
  registers via odd-numbered single-precision registers.  By
  default the
  odd-numbered single-precision registers are not used at all
  with this
  extension.  o32 FPXX code is link compatible with all other
  o32
  double-precision ABI variants and will execute correctly in
  all hardware
  FPU modes.  Enable o32 FPXX using code-mabi=32
-mfpxx/code
  for
  MIPS II onwards./li
  liThe second extension is o32 FP64A which requires 64-bit
  floating-point registers and places a mandatory restriction
on
  the use of
  odd-numbered single-precision registers.  o32 FP64A is link
  compatible
  with all other o32 double-precision ABI variants.  Enable
o32
  FP64A
  using code-mabi=32 -mfp64 -mno-odd-spreg/code for
MIPS32R2
   onwards.
  /li
  liFinally, the o32 FP64 extension which also requires 64-bit
  floating-point registers but permits the use of all single-
  precision
  registers.  Enable o32 FP64 using code-mfp64/code for
  MIPS32R2
  onwards./li
/ul
All new ABI variants can be enabled by default using configure
  time
options code--with-fp-32=[32|xx|64]/code and
code--with(out)-odd-sp-reg-32/code.  It is strongly
recommended
   that
all vendors begin to set o32 FPXX as default ABI to be able to
  run the
generated code on MIPSR5 cores alongside future MIPS SIMD
(MSA)
   code and
MIPSR6 cores./li
liWhen using binutils 2.25 GCC will now pass options like
code-msoft-float/code and code-msingle-float/code to
the
   assembler.
This change can affect inline assembly code that is built as
  soft-float but
contains hard-float instructions.  In such cases the code must
be
   amended
to use appropriate code.set/code directives to override
the
  global
assembler options./li
  /ul
   
 
  MIPS Releases 3 and 5 are now directly supported.  Use the
  command-line options -mips32r3, -mips64r3, -mips32r5 and -mips64r5 to
  enable code- generation for these processors.
 
  Support for the Imagination P5600 processor is now supported through
  use of the -march=p5600 command-line option.
 
  The Cavium Octeon3 processor is now supported through the use

RE: [PATCH,WWWDOCS] MIPS changes for GCC 5.0

2015-02-04 Thread Moore, Catherine

Hi Matthew,

I made a few edits.  I removed the markup in the process, so that will need to 
be added back.
See the text at the end.

Thanks,
Catherine

 -Original Message-
 From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
 Sent: Wednesday, February 04, 2015 11:46 AM
 To: Moore, Catherine
 Cc: 'gcc-patches@gcc.gnu.org' (gcc-patches@gcc.gnu.org)
 Subject: [PATCH,WWWDOCS] MIPS changes for GCC 5.0
 
 Hi Catherine,
 
 I've made a first pass at writing up the MIPS changes for GCC 5.0.
 Could you take a read and see what needs some more work?
 
 Thanks,
 Matthew
 
 Index: htdocs/gcc-5/changes.html
 ==
 =
 RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
 retrieving revision 1.77
 diff -r1.77 changes.html
 562a563,614
  h3 id=mipsMIPS/h3
ul
  liMIPS Releases 3 and 5 are now directly supported using code-
 mips32r3,
  -mips64r3, -mips32r5 and -mips64r5/code instead of relying on the
 Release
  2 options./li
  liSupport for the Imagination P5600 processor has been added using
  code-march=p5600/code.
  /li
  liSupport for the Cavium Networks Octeon3 processor has been added
 using
  code-march=octeon3/code./li
  liMIPS Release 6 is now supported using code-mips32r6 and -
 mips64r6
  /code.
  liThe previous o32 64-bit floating-point register support has been
  obsoleted and removed.  This was previously enabled using code-
 mfp64
  /code which has been re-purposed for the new ABI extensions
 described
  below./li
  liNew o32 ABI extensions have been added to enable software to
 transition
  away from the original layout of double-precision floating-point 
  registers.
  ul
liThe first of these extensions is o32 FPXX which places 
  restrictions
on code-generation to never access the upper 32-bits of double-
 precision
registers via odd-numbered single-precision registers.  By default the
odd-numbered single-precision registers are not used at all with this
extension.  o32 FPXX code is link compatible with all other o32
double-precision ABI variants and will execute correctly in all 
  hardware
FPU modes.  Enable o32 FPXX using code-mabi=32 -mfpxx/code for
MIPS II onwards./li
liThe second extension is o32 FP64A which requires 64-bit
floating-point registers and places a mandatory restriction on the 
  use of
odd-numbered single-precision registers.  o32 FP64A is link compatible
with all other o32 double-precision ABI variants.  Enable o32 FP64A
using code-mabi=32 -mfp64 -mno-odd-spreg/code for MIPS32R2
 onwards.
/li
liFinally, the o32 FP64 extension which also requires 64-bit
floating-point registers but permits the use of all single-precision
registers.  Enable o32 FP64 using code-mfp64/code for MIPS32R2
onwards./li
  /ul
  All new ABI variants can be enabled by default using configure time
  options code--with-fp-32=[32|xx|64]/code and
  code--with(out)-odd-sp-reg-32/code.  It is strongly recommended
 that
  all vendors begin to set o32 FPXX as default ABI to be able to run the
  generated code on MIPSR5 cores alongside future MIPS SIMD (MSA)
 code and
  MIPSR6 cores./li
  liWhen using binutils 2.25 GCC will now pass options like
  code-msoft-float/code and code-msingle-float/code to the
 assembler.
  This change can affect inline assembly code that is built as soft-float 
  but
  contains hard-float instructions.  In such cases the code must be
 amended
  to use appropriate code.set/code directives to override the global
  assembler options./li
/ul
 

MIPS Releases 3 and 5 are now directly supported.  Use the command-line options
-mips32r3, -mips64r3, -mips32r5 and -mips64r5 to enable code-generation for
these processors.

Support for the Imagination P5600 processor is now supported through
use of the -march=p5600 command-line option.

The Cavium Octeon3 processor is now supported through the use of the
command-line option -march=octeon3.

MIPS Release 6 is now supported through the use of the -mips32r6 and -mips64r6
command-line options.

The o32 ABI has been modified and extended.  The o32 64-bit floating-point
register support is now obsolete and has been removed.  It has been replaced by
three ABI extensions FPXX, FP64A, and FP64.  The meaning of the -mfp64
command-line option has been changed and it is now used to enable the ABI
extensions.

The FPXX extension requires that code generated to access double-precision
values use even-numbered registers.  Code that adheres to this extension is
link-compatible with the other o32 double-precision ABI variants and will
execute correctly in all hardware FPU modes.  The command-line options
-mabi=32 -mfpxx can be used to enable this extension.  MIPS II is the minimum
processor required.

The o32 FP64A extension

RE: [PATCH MIPS RFA] Regression cleanup for nan2008 toolchain

2015-02-03 Thread Moore, Catherine

 -Original Message-
 From: Robert Suchanek [mailto:robert.sucha...@imgtec.com]
 Sent: Monday, February 02, 2015 11:18 AM
 To: Richard Sandiford
 Cc: gcc-patches@gcc.gnu.org; Matthew Fortune; Moore, Catherine
 Subject: RE: [PATCH MIPS RFA] Regression cleanup for nan2008 toolchain

  Please could you add a comment explaining that the mips_nanlegacy is
  there because of the #include of system headers that might not compile
  with -mnan=legacy?  I agree that that's a good reason, but it's not
  obvious without a comment.  (And without a comment this could start a
  precendent of things being skipped in cases where the mips.exp options
  machinery could be updated instead.)

 True.  Clarification added.

 Ok for trunk?

 Regards,
 Robert

 2015-02-02  Robert Suchanek  robert.sucha...@imgtec.com

* gcc.target/mips/loongson-simd.c: Update comment to clarify the need
for mips_nanlegacy target.

 diff --git a/gcc/testsuite/gcc.target/mips/loongson-simd.c
 b/gcc/testsuite/gcc.target/mips/loongson-simd.c
 index 949632e..9c3ebce 100644
 --- a/gcc/testsuite/gcc.target/mips/loongson-simd.c
 +++ b/gcc/testsuite/gcc.target/mips/loongson-simd.c
 @@ -21,7 +21,10 @@ along with GCC; see the file COPYING3.  If not see
  /* { dg-do run } */
  /* loongson.h does not handle or check for MIPS16ness or
 microMIPSness.  There doesn't seem any good reason for it to, given
 -   that the Loongson processors do not support either.  */
 +   that the Loongson processors do not support either.  The effective target
 +   mips_nanlegacy is required for a toolchain without the legacy NaN support
 +   because inclusion of some system headers e.g. stdint.h will fail due to 
 not
 +   finding stubs-o32_hard.h.  */
  /* { dg-require-effective-target mips_nanlegacy } */
  /* { dg-options isa=loongson -mhard-float -mno-micromips -mno-mips16 -
 flax-vector-conversions } */

Thanks for the update.  This is OK.
Catherine

RE: [PATCH RFA MIPS] Prohibit vector modes in accumulators

2015-01-27 Thread Moore, Catherine

 -Original Message-
 From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
 Sent: Tuesday, January 27, 2015 7:19 AM
 To: Richard Sandiford
 Cc: Robert Suchanek; gcc-patches@gcc.gnu.org; Moore, Catherine
 Subject: RE: [PATCH RFA MIPS] Prohibit vector modes in accumulators

 Richard Sandiford rdsandif...@googlemail.com writes:
  Matthew Fortune matthew.fort...@imgtec.com writes:
   2015-01-23  Robert Suchanek  robert.sucha...@imgtec.com

* config/mips/mips.c (mips_hard_regno_mode_ok_p): Prohibit
   accumulators
for all vector modes.

   This seems like a genuine bug and although it can only be triggered
   by loongson or paired-single support it probably qualifies for fixing.

  Agreed FWIW.  We shouldn't mark something as valid for a mode if even
  the mode's move pattern can't handle it.

  I think this kind of thing should go in regardless of development stage.

 Given that it was one of the pre-existing tests that failed I'm happy that we
 are covering this issue. All of these LRA related issues are likely to phase 
 in
 and out with subtle changes to code-gen so I don't think we can always get a
 test case that fails on trunk.

That's true.

 Since Catherine asked for further info then I will leave her to say if she is
 happy to accept on this basis.

I withdraw my request for a testcase.

Catherine

RE: [PATCH MIPS RFA] Regression cleanup for nan2008 toolchain

2015-01-26 Thread Moore, Catherine

 -Original Message-
 From: Robert Suchanek [mailto:robert.sucha...@imgtec.com]
 Sent: Monday, January 26, 2015 6:48 AM
 To: gcc-patches@gcc.gnu.org
 Cc: Matthew Fortune; Moore, Catherine
 Subject: [PATCH MIPS RFA] Regression cleanup for nan2008 toolchain

 Hi,

 Here is a patch to clean up a large number of reported failures when a
 toolchain
 is configured with --with-nan=2008 for mips*-linux-gnu triplet and clean up a
 failures
 for mips-img-linux-gnu where nan2008 is set by the default.

 In the former case, regression involves testing e.g. -mips4 with default
 options which
 causes emission of warnings that the -mips4 architecture does not support
 nan2008, and
 hence, the test is classified as a fail (test for excess errors type of 
 error).
 The patch implies -mnan=legacy switch for all tests that are run for ISA rev 
 2.

 In the latter case, even if we decrease the ISA level for incompatible options
 for
 the loongson vector extension tests, especially loongson-simd.c, a test that
 includes
 stdint.h or stdlib.h will end up including the glibc header 'stubs-abi.h' 
 and
 will
 fail as the mipsr6 toolchain will only have stubs-o32_hard_2008.h. A toolchain
 supporting
 nan1985 will have the required stubs-o32_hard.h. The only neat solution
 AFAICS was to add
 a new effective target that tries to compile and include stdlib.h to check if 
 we
 have
 the proper support for the legacy NaN marking the concerned tests as
 UNSUPPORTED.

 Regards,
 Robert

 2015-01-26  Robert Suchanek  robert.sucha...@imgtec.com

 gcc/testsuite
   * lib/target-supports.exp (check_effective_target_mips_nanlegacy):
 New.
   * gcc.target/mips/loongson-simd.c: Require legacy NaN support.
   * gcc.target/mips/mips.exp (mips-dg-options): Imply -mnan=legacy
 for
   ISA rev  2.
 ---

This patch is OK.

RE: [PATCH RFA MIPS] Prohibit vector modes in accumulators

2015-01-23 Thread Moore, Catherine

 -Original Message-
 From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
 Sent: Friday, January 23, 2015 2:51 PM
 To: Robert Suchanek; gcc-patches@gcc.gnu.org
 Cc: Moore, Catherine
 Subject: RE: [PATCH RFA MIPS] Prohibit vector modes in accumulators

  2015-01-23  Robert Suchanek  robert.sucha...@imgtec.com

  * config/mips/mips.c (mips_hard_regno_mode_ok_p): Prohibit
  accumulators
  for all vector modes.

 This seems like a genuine bug and although it can only be triggered by
 loongson or paired-single support it probably qualifies for fixing.
 My suspicion is that the switch to LRA since GCC 4.9 may be the reason this
 hasn't been noticed before. Reload seemed better in some cases at
 eliminating bad decisions from IRA so this may have simply never made it
 through reload by fluke.

 I'd like Catherine to review too since we are in stage4 without a reproducible
 test case.

The patch looks reasonable, but I'd like to see a test case that fails before 
we agree to include for GCC 5.0.

RE: [PATCH,MIPS] Only pass floating-point options to the assembler then

2015-01-19 Thread Moore, Catherine

 -Original Message-
 From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
 Sent: Monday, January 19, 2015 5:54 PM
 To: Moore, Catherine
 Cc: 'gcc-patches@gcc.gnu.org' (gcc-patches@gcc.gnu.org)
 Subject: RE: [PATCH,MIPS] Only pass floating-point options to the assembler
 then

 Hi Catherine,

  The new behaviour of the GCC driver passing floating point options
  like -msoft-float to the assembler is essential for the new o32 ABI
  extensions but is a change in behaviour. In particular GCC 5 used with
  binutils 2.24 would require a user to fix any hand-crafted code that
  made use of floating-point instructions when building for soft-float.
  This patch limits the new behaviour to a combination of GCC and
  binutils that both have the new ABI support.

  This patch along with parts of several previous patches need
  backporting to GCC 4.9 (and GCC 4.8) to enable use of binutils 2.25
  with those compilers. The GCC 4.9 patch will be posted shortly.

 I'm not sure if you missed this patch last week or if you are unsure about it?
 Since this is about restoring previous behaviour of MIPS GCC when built
 alongside binutils = 2.24 I believe this still fits with stage4 criteria.

Hi Matthew,
I didn't miss it, but I wanted to complete some testing with it.  Those tests 
have now completed and this patch is OK.
Sorry for the delay.
Thanks,
Catherine

  gcc/
  * config/mips/mips.h (FP_ASM_SPEC): New define.
  (ASM_SPEC): Remove floating-point options and use FP_ASM_SPEC
  instead.
  ---
   gcc/config/mips/mips.h | 21 ++---
   1 file changed, 18 insertions(+), 3 deletions(-)

  diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h index
  37d4cb4..ed241fa 100644
  --- a/gcc/config/mips/mips.h
  +++ b/gcc/config/mips/mips.h
  @@ -1243,6 +1243,22 @@ struct mips_cpu_info {  %{gcoff*:-mdebug}
  %{!gcoff*:-no-mdebug}
   #endif

  +/* FP_ASM_SPEC represents the floating-point options that must be
  passed
  +   to the assembler when FPXX support exists.  Prior to that point the
  +   assembler could accept the options but were not required for
  +   correctness.  We only add the options when absolutely necessary
  +   because passing -msoft-float to the assembler will cause it to
  reject
  +   all hard-float instructions which may require some user code to be
  +   updated.  */
  +
  +#ifdef HAVE_AS_DOT_MODULE
  +#define FP_ASM_SPEC \
  +%{mhard-float} %{msoft-float} \
  +%{msingle-float} %{mdouble-float}
  +#else
  +#define FP_ASM_SPEC
  +#endif
  +
   /* SUBTARGET_ASM_SPEC is always passed to the assembler.  It may be
  overridden by subtargets.  */

  @@ -1277,9 +1293,8 @@ struct mips_cpu_info {  %{modd-spreg} %{mno-
 odd-
  spreg} \  %{mshared} %{mno-shared} \  %{msym32} %{mno-sym32} \ -
  %{mtune=*} \ -%{mhard-float} %{msoft-float} \ -%{msingle-float}
  %{mdouble-float} \
  +%{mtune=*} \
  +FP_ASM_SPEC \
   %(subtarget_asm_spec)

   /* Extra switches sometimes passed to the linker.  */
  --
  2.2.1

RE: [MIPS] Update the ZC constraint for MIPSR6 and use it

2015-01-14 Thread Moore, Catherine

 -Original Message-
 From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
 Sent: Wednesday, January 14, 2015 2:54 PM
 To: Moore, Catherine
 Cc: 'gcc-patches@gcc.gnu.org' (gcc-patches@gcc.gnu.org)
 Subject: RE: [MIPS] Update the ZC constraint for MIPSR6 and use it

 Moore, Catherine catherine_mo...@mentor.com writes
  Hi Matthew,

   -Original Message-
   From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
   Sent: Tuesday, January 06, 2015 7:43 AM
   To: Moore, Catherine
   Cc: 'gcc-patches@gcc.gnu.org' (gcc-patches@gcc.gnu.org)
   Subject: [MIPS] Update the ZC constraint for MIPSR6 and use it

   Update the ZC constraint for MIPSR6 to allow it to be used as the
   memory operand for implementations of atomic operations.  Also
   switch the internal implementation of atomic operations to use ZC
   instead of
  ZR.

   This fix accurately describes the memory constraints for the LL and
   SC instructions.  An offset can therefore be used to access a data
   item (ie. %lo (var)) rather than always having to load the address
   into a register.  Tested for mips32r2, mips32r6 and micromips.

   gcc/

 * config/mips/constraints.md (ZC): Add support for R6 LL/SC
 offsets.
 (ZD): Update to use ISA_HAS_PREF_LL_SC_9BIT.
 * config/mips/mips.h (ISA_HAS_PREFETCH_9BIT): Rename to...
 (ISA_HAS_PREF_LL_SC_9BIT): ... this. New macro.
 * config/mips/sync.md (sync_compare_and_swapmode): Use ZC
 instead of ZR for the memory operand of LL/SC.
 (compare_and_swap_12, sync_addmode): Likewise.
 (sync_optab_12, sync_old_optab_12): Likewise.
 (sync_new_optab_12, sync_nand_12): Likewise.
 (sync_old_nand_12, sync_new_nand_12): Likewise.
 (sync_submode, sync_old_addmode): Likewise.
 (sync_old_submode, sync_new_addmode): Likewise.
 (sync_new_submode, sync_optabmode): Likewise.
 (sync_old_optabmode, sync_new_optabmode):
   Likewise.
 (sync_nandmode, sync_old_nandmode): Likewise.
 (sync_new_nandmode, sync_lock_test_and_setmode):
   Likewise.
 (test_and_set_12, atomic_compare_and_swapmode): Likewise.
 (atomic_exchangemode_llsc, atomic_fetch_addmode_llsc):
   Likewise.
 * doc/md.texi (ZC): Update description.

   OK to commit?

   diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h index
   9dad480..b608b17 100644
   --- a/gcc/config/mips/mips.h
   +++ b/gcc/config/mips/mips.h
   @@ -1089,8 +1089,8 @@ struct mips_cpu_info {
   || mips_isa_rev = 1) \
   !TARGET_MIPS16)

   -/* ISA has data prefetch with limited 9-bit displacement.  */
   -#define ISA_HAS_PREFETCH_9BIT(mips_isa_rev = 6)
   +/* ISA has data prefetch, LL and SC with limited 9-bit displacement.
  */
   +#define ISA_HAS_PREF_LL_SC_9BIT  (mips_isa_rev = 6)

  I'd like to see this described as something more general.  Say:
  ISA_HAS_9BIT_DISPLACEMENT.   This patch is okay with that fixup.

 I think I'm OK with changing that but it does leave us with a different issue 
 of
 knowing which subset of instructions should check for 9-bit displacement.
 I.e. not all instructions only have a 9-bit displacement.

I'm open to a different name.  Do you have any other suggestions?   Can we just 
say = R6?

 A GCC 6 thing would be to look over all the ISA_HAS macros and perhaps do
 some general improvement in the framework we have there. I don't know
 exactly what I'd do but something a bit more table based seems sensible.

Sounds like a good idea.

RE: [MIPS] Update the ZC constraint for MIPSR6 and use it

2015-01-14 Thread Moore, Catherine

Hi Matthew,

 -Original Message-
 From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
 Sent: Tuesday, January 06, 2015 7:43 AM
 To: Moore, Catherine
 Cc: 'gcc-patches@gcc.gnu.org' (gcc-patches@gcc.gnu.org)
 Subject: [MIPS] Update the ZC constraint for MIPSR6 and use it

 Update the ZC constraint for MIPSR6 to allow it to be used as the memory
 operand for implementations of atomic operations.  Also switch the internal
 implementation of atomic operations to use ZC instead of ZR.

 This fix accurately describes the memory constraints for the LL and SC
 instructions.  An offset can therefore be used to access a data item
 (ie. %lo (var)) rather than always having to load the address into a
 register.  Tested for mips32r2, mips32r6 and micromips.

 gcc/

   * config/mips/constraints.md (ZC): Add support for R6 LL/SC
   offsets.
   (ZD): Update to use ISA_HAS_PREF_LL_SC_9BIT.
   * config/mips/mips.h (ISA_HAS_PREFETCH_9BIT): Rename to...
   (ISA_HAS_PREF_LL_SC_9BIT): ... this. New macro.
   * config/mips/sync.md (sync_compare_and_swapmode): Use ZC
   instead of ZR for the memory operand of LL/SC.
   (compare_and_swap_12, sync_addmode): Likewise.
   (sync_optab_12, sync_old_optab_12): Likewise.
   (sync_new_optab_12, sync_nand_12): Likewise.
   (sync_old_nand_12, sync_new_nand_12): Likewise.
   (sync_submode, sync_old_addmode): Likewise.
   (sync_old_submode, sync_new_addmode): Likewise.
   (sync_new_submode, sync_optabmode): Likewise.
   (sync_old_optabmode, sync_new_optabmode):
 Likewise.
   (sync_nandmode, sync_old_nandmode): Likewise.
   (sync_new_nandmode, sync_lock_test_and_setmode):
 Likewise.
   (test_and_set_12, atomic_compare_and_swapmode): Likewise.
   (atomic_exchangemode_llsc, atomic_fetch_addmode_llsc):
 Likewise.
   * doc/md.texi (ZC): Update description.

 OK to commit?

 diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
 index 9dad480..b608b17 100644
 --- a/gcc/config/mips/mips.h
 +++ b/gcc/config/mips/mips.h
 @@ -1089,8 +1089,8 @@ struct mips_cpu_info {
 || mips_isa_rev = 1) \
 !TARGET_MIPS16)

 -/* ISA has data prefetch with limited 9-bit displacement.  */
 -#define ISA_HAS_PREFETCH_9BIT(mips_isa_rev = 6)
 +/* ISA has data prefetch, LL and SC with limited 9-bit displacement.  */
 +#define ISA_HAS_PREF_LL_SC_9BIT  (mips_isa_rev = 6)

I'd like to see this described as something more general.  Say:
ISA_HAS_9BIT_DISPLACEMENT.   This patch is okay with that fixup.
Thanks,
Catherine

1 2 >

1 - 100 of 165 matches

Mail list logo