course is to update
autotools to something more recent.
--
Alan Modra
Australia Development Lab, IBM
restore the state of symbols to what they
would be without that object. (Yes, we do that sort of thing for
as-needed shared libraries, but the restoration happens immediately
after adding the symbols. I also regret implementing it the way I
did.)
The patch posted is OK from the linker side of things.
(DW_AT_namelist_items, 0x44)
+DW_AT (DW_AT_namelist_item, 0x44)
DW_AT (DW_AT_priority, 0x45)
DW_AT (DW_AT_segment, 0x46)
DW_AT (DW_AT_specification, 0x47)
--
Alan Modra
Australia Development Lab, IBM
On Mon, May 23, 2022 at 07:42:29PM -0400, David Malcolm via Binutils wrote:
> Any objections, or is there a reason to keep these macros that I'm
> not aware of? (and did I send this to all the pertinent lists?)
No objection from me. These macros are not used anywhere in
binutils-gdb.
--
>else
> -nentries = (PTR *) (*htab->alloc_f) (nsize, sizeof (PTR *));
> +nentries = (void **) (*htab->alloc_f) (nsize, sizeof (void **));
>if (nentries == NULL)
> return 0;
>htab->entries = nentries;
Here too.
--
Alan Modra
Australia Development Lab, IBM
currences of PTR in the cgen generated parts of opcodes,
sim, and even gdb. I have a few patches I haven't yet committed.
--
Alan Modra
Australia Development Lab, IBM
+configure-stageautofeedback-opcodes: configure-stageautofeedback-bfd
install-opcodes: maybe-install-bfd
install-strip-opcodes: maybe-install-strip-bfd
configure-gas: maybe-configure-intl
--
Alan Modra
Australia Development Lab, IBM
#ifndef __attribute_pure__
# if defined __GNUC_MINOR__ && __GNUC__ * 1000 + __GNUC_MINOR__ >= 2096
--
Alan Modra
Australia Development Lab, IBM
On Wed, Jul 21, 2021 at 08:59:04AM -0400, David Edelsohn wrote:
> On Wed, Jul 21, 2021 at 4:29 AM Alan Modra wrote:
> >
> > On Wed, Jul 14, 2021 at 08:24:16PM -0400, David Edelsohn wrote:
> > > > > > * config/rs6000/morestack.S (R2_SAVE): Define.
&g
s://www.gnu.org/software/libtool/
>
> I considered this, but there is *serious* divergence between the
> libtool.m4 in our tree and upstream. Fixing this divergence looks to be
> a fairly major project in and of itself :( the last real sync looked
> like being all the way back in 2008.
Ye
On Wed, Jun 30, 2021 at 05:06:30PM -0300, Tulio Magno Quites Machado Filho
wrote:
> Alan Modra via Gcc-patches writes:
>
> > Compiling gcc/testsuite/gcc.dg/split-*.c and others with -mcpu=power10
> > and linking with a non-pcrel libgcc results in crashes due to the
>
On Thu, Jul 01, 2021 at 04:47:21PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jul 01, 2021 at 10:59:15PM +0930, Alan Modra wrote:
> > * lib/target-supports.exp (check_effective_target_has_arch_pwr10): New.
>
> Mike added this already, please make sure to not
wr10 assembly {
+ #ifndef _ARCH_PWR10
+ #error does not have power10 support.
+ #else
+ /* "has power10 support" */
+ #endif
+ }]
+}
+
# Return 1 if this is a PowerPC target supporting -mcpu=power10.
# Limit this to 64-bit linux systems for now until other targets support
# power10.
--
Alan Modra
Australia Development Lab, IBM
2
+ ld %r2,R2_SAVE(%r29)
+#endif
ld %r3,PARAMREG_SAVE+0(%r29)
ld %r4,PARAMREG_SAVE+8(%r29)
ld %r5,PARAMREG_SAVE+16(%r29)
--
Alan Modra
Australia Development Lab, IBM
ute new gcc work. This one was
just flushing some patches that I wrote a while ago.
--
Alan Modra
Australia Development Lab, IBM
On Mon, May 10, 2021 at 04:39:55PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Fri, May 07, 2021 at 12:19:52PM +0930, Alan Modra wrote:
> > PowerPC64 ELFv2 dual entry point functions have a couple of problems
> > with -fpatchable-function-entry. One is that the nops added
alias_target ();
- const char *name = IDENTIFIER_POINTER (id);
- name = targetm.strip_name_encoding (name);
- fprintf (asm_out_file, ",%s", name);
+ fprintf (asm_out_file, ",");
+ assemble_name_raw (asm_out_file, func_label);
}
if (HAVE_COMDAT_GROUP && (flags & SECTION_LINKONCE))
{
--
Alan Modra
Australia Development Lab, IBM
PowerPC64 ELFv2 dual entry point functions have a couple of problems
with -fpatchable-function-entry. One is that the nops added after the
global entry land in the global entry code which is constrained to be
a power of two number of instructions, and zero global entry code has
special meaning
This reverts commit b680b9049737198d010e49cf434704c6a6ed2b3f now
that the PowerPC64 ELFv1 regression is fixed properly.
PR testsuite/98125
* targhooks.h (default_print_patchable_function_entry_1): Delete.
* targhooks.c (default_print_patchable_function_entry_1): Delete.
On PowerPC64 ELFv1 function symbols are defined on function
descriptors in an .opd section rather than in the function code.
.opd is not split up by the PowerPC64 backend for comdat groups or
other situations where per-function sections are required. Thus
SECTION_LINK_ORDER can't use the function
targets, libgo runtime/pprof. It's unclear to
me what that means.
Alan Modra (3):
PowerPC64 ELFv1 -fpatchable-function-entry
Revert "rs6000: Avoid -fpatchable-function-entry* regressions on
powerpc64 be [PR98125]"
PowerPC64 ELFv2 -fpatchable-function-entry
gcc/config/rs6000/rs60
On Wed, May 05, 2021 at 08:05:29AM +0100, Iain Sandoe wrote:
> Alan Modra via Gcc-patches wrote:
>
> > On 2021-05-04 8:42 a.m., Nick Clifton wrote:
> > > Hi Guys,
> > >
> > > On 4/30/21 7:36 PM, Simon Marchi wrote:
> > > > I think
fig/i386/i386.h
@@ -73,8 +73,8 @@ struct stringop_algs
{
const enum stringop_alg unknown_size;
const struct stringop_strategy {
-const int max;
-const enum stringop_alg alg;
+int max;
+enum stringop_alg alg;
int noalign;
} size [MAX_STRINGOP_ALGS];
};
--
Alan Modra
A
at top-level somehow does not
> play well with the C11 check in sim/? Like if that would cause CC to be
> set to "gcc -std=gnu99 -std=gnu11" or something like that.
>
> Simon
--
Alan Modra
Australia Development Lab, IBM
tch to make ppc-dis.c
> compile again with C89, but if we're going to update configure.ac
> appropriately, then it wouldn't be needed.
Yes, I prefer the configure fix too. If we state we require C99 in
binutils then we ought to be able to use C99..
Nick, does the configure.ac change also need to go in all subdirs, to
support people running make in say ld/ rather than running make in the
top build dir?
--
Alan Modra
Australia Development Lab, IBM
pect ".retain foo" to create a separate .data
section for foo? If you do, I'm strongly against that idea.
Note that gas indeed supports multiple sections named .data that can
serve the same purpose as -fdata-sections. See the gas doc for the
optional .section field "unique". That might be the best way to avoid
an under-the-hood -ffunction-sections/-fdata-sections.
--
Alan Modra
Australia Development Lab, IBM
On Mon, Feb 08, 2021 at 11:16:31AM +, Nick Alcock via Binutils wrote:
> intl/ChangeLog
> 2021-02-04 Nick Alcock
>
> * configure.ac (LIBINTL): Transform into -L/-lintl form.
> * configure: Regenerate.
OK for binutils.
--
Alan Modra
Australia Development Lab, IBM
(COMPILE): Use it.
> * configure: Regenerate.
OK for binutils.
--
Alan Modra
Australia Development Lab, IBM
;-mno-prefixed" { target { lp64 } } } */
in order to keep scan-assembler-times counts correct for power10.
--
Alan Modra
Australia Development Lab, IBM
On Mon, Jan 25, 2021 at 04:51:43PM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Oct 08, 2020 at 09:27:57AM +1030, Alan Modra wrote:
> > * config/rs6000/rs6000.c (rotate_insert_cost): New function.
> > (rs6000_rtx_costs): Cost IOR.
> >
> > diff --g
nsistency I made the change in old code too.
--
Alan Modra
Australia Development Lab, IBM
Ping.
On Tue, Jan 12, 2021 at 02:03:18PM +1030, Alan Modra wrote:
> Ping
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557587.html
>
> On Fri, Oct 30, 2020 at 07:00:14PM +1030, Alan Modra wrote:
> > And now waking up to what you meant by the lvsl-lvsr.c \s comment,
Ping.
On Tue, Jan 12, 2021 at 02:02:36PM +1030, Alan Modra wrote:
> Ping
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555759.html
>
> On Thu, Oct 08, 2020 at 09:28:00AM +1030, Alan Modra wrote:
> > When optimizing for size we shouldn't be using metrics based on
Ping.
On Tue, Jan 12, 2021 at 02:02:27PM +1030, Alan Modra wrote:
> Ping
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555758.html
>
> On Thu, Oct 08, 2020 at 09:27:59AM +1030, Alan Modra wrote:
> > The aim of this patch is to make rtx_costs for SETs closer to
>
Ping.
On Tue, Jan 12, 2021 at 02:02:18PM +1030, Alan Modra wrote:
> Ping
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555756.html
>
> On Thu, Oct 08, 2020 at 09:27:57AM +1030, Alan Modra wrote:
> > * config/rs6000/rs6000.c (rotate_insert_c
Ping.
On Tue, Jan 12, 2021 at 02:02:09PM +1030, Alan Modra wrote:
> Ping
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555755.html
>
> On Thu, Oct 08, 2020 at 09:27:56AM +1030, Alan Modra wrote:
> > Most cases use "return false" rather than breaking out of
Ping.
On Tue, Jan 12, 2021 at 02:01:57PM +1030, Alan Modra wrote:
> Ping
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555754.html
>
> On Thu, Oct 08, 2020 at 09:27:55AM +1030, Alan Modra wrote:
> > * config/rs6000/rs6000.c (rs6000_rtx_costs): Tidy AND code.
&
On Mon, Jan 11, 2021 at 02:52:43PM -0800, H.J. Lu wrote:
> On Mon, Jan 11, 2021 at 1:20 PM Alan Modra wrote:
> >
> > On Mon, Jan 11, 2021 at 11:53:15AM -0800, H.J. Lu via Binutils wrote:
> > > Check if AR is usable for LTO build with --enable-pgo-build=lto:
> > >
On Mon, Jan 11, 2021 at 04:07:22PM -0800, H.J. Lu wrote:
> These are not fatal errors. Here is the updated patch to use
> AC_MSG_WARN instead. OK for master?
OK by me. Please squash the two patches.
--
Alan Modra
Australia Development Lab, IBM
quot;$plugin_option"; then
>if $AR --help 2>&1 | grep -q "\--plugin"; then
> -AR="$AR $plugin_option"
> +touch conftest.c
> +$AR $plugin_option rc conftest.a conftest.c
> +if test "$?" != 0; then
> + echo "Failed: $AR $plugin_option rc"
AC_MSG_ERROR again.
> +else
> + AR="$AR $plugin_option"
> +fi
> +rm -f conftest.*
>fi
> fi
> test -z "$AR_FLAGS" && AR_FLAGS=cru
--
Alan Modra
Australia Development Lab, IBM
email.
--
Alan Modra
Australia Development Lab, IBM
On Sat, Dec 05, 2020 at 07:42:07PM +1030, Alan Modra wrote:
> Hi Segher,
> I've been holding off pinging these knowing you had a lot of other
> review work, but maybe that's settling down now? You already OK'd
> 1/8, 2/8 and 6/8.
Ping.
> [PATCH 3/8] [RS6000] rs6000_rtx_costs t
LIB_PLUGIN_OPTION="$PLUGIN_OPTION"
>fi
> +else
> + if test "$enable_pgo_build" != "no"; then
> +AC_MSG_ERROR([AR with --plugin and rc is required for LTO build])
> + fi
> fi
> AC_SUBST(AR_PLUGIN_OPTION)
> AC_SUBST(RANLIB_PLUGIN_OPTION)
> --
> 2.29.2
--
Alan Modra
Australia Development Lab, IBM
ld fix that easily enough but I'm going to ask that you
post a combined patch to bring the gcc repo up to date with any libctf
changes.
--
Alan Modra
Australia Development Lab, IBM
ore-builtin_vec_xst-longlong.c, due to
-mdejagnu-cpu=power8 in that test meaning we don't see any power10
insns.
--
Alan Modra
Australia Development Lab, IBM
On Thu, Oct 29, 2020 at 10:10:58PM +1030, Alan Modra wrote:
> Fixes
> FAIL: gcc.target/powerpc/signbit-1.c scan-assembler-not stxvd2x
> FAIL: gcc.target/powerpc/signbit-1.c scan-assembler-times mfvsrd 3
> FAIL: gcc.target/powerpc/signbit-1.c scan-assembler-times srdi 3
> FAIL: gcc
for power10 instructions V3
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557587.html
--
Alan Modra
Australia Development Lab, IBM
3cb 100644
--- a/libgcc/config/rs6000/t-ppc64-fp
+++ b/libgcc/config/rs6000/t-ppc64-fp
@@ -1,2 +1 @@
-# Can be used unconditionally, wrapped in __powerpc64__ || __64BIT__ __ppc64__.
-LIB2ADD += $(srcdir)/config/rs6000/ppc64-fp.c
+LIB2_SIDITI_CONV_FUNCS = yes
--
Alan Modra
Australia Development Lab, IBM
On Tue, Nov 10, 2020 at 09:19:37PM -0700, Jeff Law wrote:
> I think the const char * is fine. That should force resolution to the
> same routine we were using earlier. Do you want to commit that fix or
> shall I?
Commited 693a79a355e1.
--
Alan Modra
Australia Development Lab, IBM
^
/home/alan/src/gcc/gcc/tree.h:4284:13: note: candidate: void
set_decl_section_name(tree, const_tree)
extern void set_decl_section_name (tree, const_tree);
^
I'm using the obvious to me "(const char *) NULL" in the call to fix
this, but you might like a different style C++ fix instead.
--
Alan Modra
Australia Development Lab, IBM
ibute__ ((__noclone__, __noinline__))
+stack_args (int j1, int j2, int j3, int j4, int j5, int j6, int j7, int j8,
+ int j9)
+{
+ if (j9 == 0)
+return 0;
+ return reg_args (j1, j2, j3, j4, j5, j6, j7, j8);
+}
+
+/* { dg-final { scan-assembler-not {(?n)^\s+bl\s} } } */
--
Alan Modra
Australia Development Lab, IBM
On Sat, Oct 31, 2020 at 12:10:35AM +1030, Alan Modra wrote:
> Would it be better if I post the patches again, restructuring them as
> 1) completely no functional change just moving the existing condition
>to the powerpc and i386 target hooks, and
> 2) twiddling the powerpc
ribute
And, yes, I completely agree that libgcc_s.so should not be marked
with .gnu_attribute.
> # This is a way of selecting -mcmodel=small for ppc64, which gives
> # smaller and faster libgcc code. Directly specifying -mcmodel=small
> --
> 2.22.0
>
>
> --
> Michael Meissner, IBM
> IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
> email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
--
Alan Modra
Australia Development Lab, IBM
On Fri, Oct 30, 2020 at 09:21:09AM +, Richard Sandiford wrote:
> Alan Modra via Gcc-patches writes:
> > This moves an #ifdef block of code from calls.c to
> > targetm.function_ok_for_sibcall. Only two targets, x86 and rs6000,
> > define REG_PARM_STACK_SPACE or OUTGOING
quot;has power10 support" */
+ #endif
+ }]
+}
+
# Return 1 if this is a PowerPC target supporting -mcpu=power10.
# Limit this to 64-bit linux systems for now until other targets support
# power10.
--
Alan Modra
Australia Development Lab, IBM
et lp64 } } } */
+/* { dg-final { scan-assembler-times "lwz"1 { target ilp32 } } } */
+/* { dg-final { scan-assembler-times "rlwinm" 1 { target ilp32 } } } */
--
Alan Modra
Australia Development Lab, IBM
gnbit-2.c scan-assembler-times srdi 1
I'm not complaining about that, or demanding that you fix those fails;
In fact I'm in the middle of fixing them. But they do quite perfectly
illustrate that tweaking the testsuite is never simple.
--
Alan Modra
Australia Development Lab, IBM
On Wed, Oct 28, 2020 at 01:44:54PM -0500, Segher Boessenkool wrote:
> On Wed, Oct 28, 2020 at 09:18:35PM +1030, Alan Modra wrote:
> > >From e7ce33cef478a826a2fe4e110b43b49586ef2438 Mon Sep 17 00:00:00 2001
> > From: Alan Modra
> > Date: Wed, 28 Oct 2020 15:57:57 +1030
On Wed, Oct 28, 2020 at 12:16:00PM -0500, Segher Boessenkool wrote:
> On Wed, Oct 28, 2020 at 09:20:56PM +1030, Alan Modra wrote:
> > Otherwise some versions of dejagnu go ahead and run the vsx tests
> > below when they should not. To best cope with older dejagnu, put
> >
ent) */
-/* { dg-do compile {target power10_ok} } */
-/* { dg-do run {target power10_hw} } */
+/* { dg-do run { target power10_hw } } */
+/* { dg-do compile { target { ! power10_hw } } } */
+/* { dg-require-effective-target power10_ok } */
/* { dg-require-effective-target int128 } */
/* Deliberately set optization to zero for this test to confirm
--
Alan Modra
Australia Development Lab, IBM
>From e7ce33cef478a826a2fe4e110b43b49586ef2438 Mon Sep 17 00:00:00 2001
From: Alan Modra
Date: Wed, 28 Oct 2020 15:57:57 +1030
Subject:
I noticed this test is unsupported on power10 when looking through
test logs. There seems no reason why that should be the case, ie.
likely the target t
_set (b, set_members); /* { dg-warning "implicit
declaration of function" } */
}
--
Alan Modra
Australia Development Lab, IBM
mes {\mlxv\M} 8 { target ilp32 } } } */
/* { dg-final { scan-assembler-times {\mlvewx\M} 4 { target ilp32 } } } */
--
Alan Modra
Australia Development Lab, IBM
On Tue, Oct 27, 2020 at 05:34:45PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Oct 27, 2020 at 09:26:10PM +1030, Alan Modra wrote:
> > These tests never checked assembly, because .s files were not
> > produced. One test was looking for the wrong instructions.
>
c
@@ -9,7 +9,7 @@
the stxvr*x instruction is generated. At higher optimization levels
the instruction we are looking for is sometimes replaced by other
store instructions. */
-/* { dg-options "-mdejagnu-cpu=power10 -O0" } */
+/* { dg-options "-mdejagnu-cpu=power10 -O0
>From 6c1817cece47ce2cb36df1f57b533b9d2385f0a5 Mon Sep 17 00:00:00 2001
From: Alan Modra
Date: Tue, 27 Oct 2020 17:32:13 +1030
Subject:
These tests never checked assembly, because .s files were not
produced. One test was looking for the wrong instructions.
A typical error log
PASS: gcc.tar
{ int128 && power10_ok } } */
+/* { dg-require-effective-target power10_ok } */
+/* { dg-require-effective-target int128 } */
/* Check that the expected 128-bit instructions are generated if the processor
supports the 128-bit integer instructions. */
--
Alan Modra
Australia Development Lab, IBM
rget/powerpc/pr86731-fwrapv-longlong.c
@@ -30,5 +30,5 @@ vector signed long long splats4(void)
/* { dg-final { scan-assembler-times {\mvspltis[bhw]\M} 0 } } */
/* { dg-final { scan-assembler-times {\mvsl[bhwd]\M} 0 } } */
-/* { dg-final { scan-assembler-times {\mlvx\M|\mlxv\M|\mlxvd2x\M} 2 } } */
+/* { dg-final { scan-assembler-times {\mlvx\M|\mp?lxv\M|\mlxvd2x\M} 2 } } */
--
Alan Modra
Australia Development Lab, IBM
ps-p8-22.c
+++ b/gcc/testsuite/gcc.target/powerpc/swaps-p8-22.c
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target { *-*-aix* || { *-*-linux* && lp64 } } } } */
/* { dg-require-effective-target powerpc_p8vector_ok } */
/* { dg-options "-O2 -mdejagnu-cpu=power8 -maltivec -mcmodel=large" } */
--
Alan Modra
Australia Development Lab, IBM
On Mon, Oct 26, 2020 at 07:33:49AM -0500, Segher Boessenkool wrote:
> On Sun, Oct 25, 2020 at 09:50:01PM +1030, Alan Modra wrote:
> > All these tests fail with -m32 due to lack of int128 support,
>
> Is there any good reason __int128 is not enabled for rs6000 -m32, btw?
Lack of ad
On Mon, Oct 26, 2020 at 03:18:39PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Oct 22, 2020 at 05:28:17PM +1030, Alan Modra wrote:
> > These tests require -mno-pcrel because they are testing features
> > of the non-pcrel ABI.
>
> > --- a/gcc/testsuite/
On Sun, Oct 25, 2020 at 10:43:12AM -0400, David Edelsohn wrote:
> On Sun, Oct 25, 2020 at 7:20 AM Alan Modra wrote:
> >
> > All these tests fail with -m32 due to lack of int128 support, in some
> > cases with what I thought was not the best error message. For example
> &g
long long swap_load (long long *a) { return __builtin_bswap64 (*a); }
long long swap_reg (long long a) { return __builtin_bswap64 (a); }
void swap_store (long long *a, long long b) { *a = __builtin_bswap64 (b); }
--
Alan Modra
Australia Development Lab, IBM
ctive-target power10_ok } */
-/* { dg-options "-O2 -mdejagnu-cpu=power10 -mpcrel" } */
+/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
int array[8];
int
--
Alan Modra
Australia Development Lab, IBM
&& powerpc_p8vector_ok } } */
/* { dg-options "-O2 -mdejagnu-cpu=power8 -maltivec -mcmodel=large" } */
/* The expansion for vector character multiply introduces a vperm operation.
--
Alan Modra
Australia Development Lab, IBM
8 && power10_ok } } */
/* Check that the expected 128-bit instructions are generated if the processor
supports the 128-bit integer instructions. */
--
Alan Modra
Australia Development Lab, IBM
On Sat, Oct 24, 2020 at 12:31:43PM -0500, Segher Boessenkool wrote:
> On Sat, Oct 24, 2020 at 02:59:34PM +1030, Alan Modra wrote:
> > Those instructions aren't generated, we don't see them anywhere on a
> > power10 all-lang bootstrap except in one testcase designed to ex
On Fri, Oct 23, 2020 at 04:06:57PM -0500, Segher Boessenkool wrote:
> On Fri, Oct 23, 2020 at 09:41:30AM +1030, Alan Modra wrote:
> > On Thu, Oct 22, 2020 at 11:03:14AM -0500, Segher Boessenkool wrote:
> > > On Thu, Oct 22, 2020 at 08:58:10AM -0700, Carl Love wrote:
>
Hi Segher,
On Fri, Oct 23, 2020 at 11:31:02AM -0500, Segher Boessenkool wrote:
> On Fri, Oct 23, 2020 at 05:15:08PM +1030, Alan Modra wrote:
> > The problem starts with fwprop creating
> > (insn 9 4 0 2 (set (mem:V8HI (and:DI (plus:DI (reg/v/f:DI 121 [ vpp ])
> >
On Fri, Oct 23, 2020 at 07:18:44PM -0400, Hans-Peter Nilsson wrote:
> On Thu, 22 Oct 2020, Alan Modra via Gcc-patches wrote:
> > /* (reg) is costed at zero by rtlanal.c:rtx_cost. That sets a
> > baseline for rtx costs: If a constant is valid in an insn,
>
On Fri, Oct 23, 2020 at 01:22:31PM -0500, Segher Boessenkool wrote:
> On Fri, Oct 23, 2020 at 04:45:29PM +1030, Alan Modra wrote:
> > Revised patch, removing changes to
> > gcc.target/powerpc/fold-vec-st-double.c,
> > gcc.target/powerpc/fold-vec-st-longlong.c,
> > gcc
ET_POWER10 && TARGET_ISEL)
rs6000_emit_int_cmove (operands[0], operands[1], const1_rtx, const0_rtx);
/* Expanding EQ and NE directly to some machine instructions does not help
--
Alan Modra
Australia Development Lab, IBM
ters_memory_p (x));
+}
- if (TARGET_ELF && RS6000_SYMBOL_REF_TLS_P (x))
-return 0;
if (legitimate_indirect_address_p (x, reg_ok_strict))
return 1;
if (TARGET_UPDATE
--
Alan Modra
Australia Development Lab, IBM
On Thu, Oct 22, 2020 at 11:25:09PM +1030, Alan Modra wrote:
> Some of these are wrong, sorry. I need to go over and check them
> thoroughly. Please consider the patch withdrawn.
Revised patch, removing changes to
gcc.target/powerpc/fold-vec-st-double.c,
gcc.target/powerpc/fold-vec-st-long
ns
Line Length
Lines shall be at most 80 columns."
Seriously, it doesn't matter what you or I think about the formatting
rules, they are in place for good reason.
--
Alan Modra
Australia Development Lab, IBM
t;dg_require_effective_target power10_hw" do
nothing at all if not on power10 hardware. The single test that might
have caught the problem, vec-splati-runnable.c wasn't even compiled.
That's why I submitted
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556757.html
--
Alan Modra
Australia Development Lab, IBM
On Thu, Oct 22, 2020 at 05:33:46PM +1030, Alan Modra wrote:
> * gcc.dg/pr56727-2.c,
> * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c,
> * gcc.target/powerpc/fold-vec-load-builtin_vec_xl-char.c,
> * gcc.target/powerpc/fold-vec-load-builtin_vec
On Mon, Oct 12, 2020 at 10:37:05PM +1030, Alan Modra wrote:
> Ping?
>
> On Fri, Oct 02, 2020 at 05:03:50PM +0930, Alan Modra wrote:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555309.html
Ping^2
--
Alan Modra
Australia Development Lab, IBM
g-final { scan-assembler-times {\mvsl[bhwd]\M} 0 } } */
-/* { dg-final { scan-assembler-times {\mlvx\M|\mlxv\M|\mlxvd2x\M} 2 } } */
+/* { dg-final { scan-assembler-times {\mlvx\M|\mlxv\M|\mlxvd2x\M|\mplxv\M} 2 }
} */
--
Alan Modra
Australia Development Lab, IBM
able.c
+++ b/gcc/testsuite/gcc.target/powerpc/vsx_mask-move-runnable.c
@@ -1,6 +1,7 @@
-/* { dg-do run } */
+/* { dg-do run { target { power10_hw } } } */
+/* { dg-do link { target { ! power10_hw } } } */
/* { dg-options "-mcpu=power10 -O2" } */
-/* { dg-require-effective-target power10_hw
ong long y) { *(long long *) (x + 32766) = y; }
--
Alan Modra
Australia Development Lab, IBM
cc/testsuite/gcc.target/powerpc/r2_shrink-wrap.c
@@ -1,5 +1,5 @@
/* { dg-do compile { target lp64 } } */
-/* { dg-options "-O2 -fdump-rtl-pro_and_epilogue" } */
+/* { dg-options "-O2 -fdump-rtl-pro_and_epilogue -mno-pcrel" } */
/* Verify we move the prologue past the TOC reference of 'j' and shrink-wrap
the function. */
--
Alan Modra
Australia Development Lab, IBM
pected_vresult_d[%i] = %e\n",
i, vresult_d[i], i, expected_vresult_d[i]);
#else
-abort();
+;
#endif
}
--
Alan Modra
Australia Development Lab, IBM
[(match_operand:VSX_MM 1 "vsx_register_operand" "v")]
UNSPEC_VEXPAND))]
"TARGET_POWER10"
- "vexpandm %0,%1"
+ "vexpandm %0,%1"
[(set_attr "type" "vecsimple")])
--
Alan Modra
Australia Development Lab, IBM
; It should return COSTS_N_INSNS (2) for that?
No, it should not!
/* (reg) is costed at zero by rtlanal.c:rtx_cost. That sets a
baseline for rtx costs: If a constant is valid in an insn,
it is free. */
--
Alan Modra
Australia Development Lab, IBM
On Tue, Oct 20, 2020 at 01:55:56PM -0500, Segher Boessenkool wrote:
> On Thu, Oct 08, 2020 at 09:27:54AM +1030, Alan Modra wrote:
> > The existing "case AND" in this function is not sufficient for
> > optabs.c:avoid_expensive_constant usage, where the AND is passed in
&
Ping?
On Fri, Oct 02, 2020 at 05:03:50PM +0930, Alan Modra wrote:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555309.html
--
Alan Modra
Australia Development Lab, IBM
This small patch to rs6000_rtx_costs considerably improves code
generated for large constants in 64-bit code, teaching gcc that it is
better to load a constant from memory than to generate a sequence of
up to five dependent instructions. Note that the rs6000 backend does
generate large constants
When optimizing for size we shouldn't be using metrics based on speed
or vice-versa. rtlanal.c:get_full_rtx_cost wants both speed and size
metric from rs6000_rtx_costs independent of the global optimize_size.
Note that the patch changes param_simultaneous_prefetches,
param_l1_cache_size,
This is a revised version of the patch series posted at
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553919.html
Patch 8/8 in particular changes rather a lot more than the original
!speed changes. Bootstrapped and regression tested powerpc64le-linux
and powerpc64-linux biarch.
Alan
1 - 100 of 986 matches
Mail list logo
