[PATCH 5/8] [RS6000] rs6000_rtx_costs cost IOR

2020-10-07 Thread Alan Modra via Gcc-patches
* config/rs6000/rs6000.c (rotate_insert_cost): New function. (rs6000_rtx_costs): Cost IOR. diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c index 383d2901c9f..15a806fe307 100644 --- a/gcc/config/rs6000/rs6000.c +++ b/gcc/config/rs6000/rs6000.c @@ -21206,6 +21206

[PATCH 3/8] [RS6000] rs6000_rtx_costs tidy AND

2020-10-07 Thread Alan Modra via Gcc-patches
* config/rs6000/rs6000.c (rs6000_rtx_costs): Tidy AND code. Don't avoid recursion on const_int shift count. diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c index e870ba0039a..bc5e51aa5ce 100644 --- a/gcc/config/rs6000/rs6000.c +++ b/gcc/config/rs6000/rs6000.c @

[PATCH 7/8] [RS6000] rs6000_rtx_costs reduce cost for SETs

2020-10-07 Thread Alan Modra via Gcc-patches
The aim of this patch is to make rtx_costs for SETs closer to insn_cost for SETs. One visible effect on powerpc code is increased if-conversion. * config/rs6000/rs6000.c (rs6000_rtx_costs): Reduce cost of SET operands. diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/r

[PATCH 2/8] [RS6000] rs6000_rtx_costs for AND

2020-10-07 Thread Alan Modra via Gcc-patches
The existing "case AND" in this function is not sufficient for optabs.c:avoid_expensive_constant usage, where the AND is passed in outer_code. We'd like to cost AND of rs6000_is_valid_and_mask or rs6000_is_valid_2insn_and variety there, so that those masks aren't seen as expensive (ie. better to l

[PATCH 0/8] [RS6000] rs6000_rtx_costs V2

2020-10-07 Thread Alan Modra via Gcc-patches
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

[PATCH 6/8] [RS6000] rs6000_rtx_costs multi-insn constants

2020-10-07 Thread Alan Modra via Gcc-patches
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 a

[PATCH 8/8] [RS6000] rs6000_rtx_costs for !speed

2020-10-07 Thread Alan Modra via Gcc-patches
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, param_l1

Re: [PATCH] Remove non-ANSI C macros in ansidecl.h.

2022-05-10 Thread Alan Modra via Gcc-patches
ere are occurrences 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

Re: [PATCH] libiberty: stop using PTR macro.

2022-05-10 Thread Alan Modra via Gcc-patches
*)); >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

Re: [PATCH] libiberty: remove FINAL and OVERRIDE from ansidecl.h

2022-05-24 Thread Alan Modra via Gcc-patches
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

[PATCH 1/2] can_implement_as_sibling_call_p REG_PARM_STACK_SPACE check V2

2020-11-02 Thread Alan Modra via Gcc-patches
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 target h

[PATCH 2/2] [RS6000] REG_PARM_STACK_SPACE check V2

2020-11-02 Thread Alan Modra via Gcc-patches
} + +int __attribute__ ((__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

Re: [PATCH 1/3] Refactor copying decl section names

2020-11-10 Thread Alan Modra via Gcc-patches
^ /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

Re: [PATCH 1/3] Refactor copying decl section names

2020-11-10 Thread Alan Modra via Gcc-patches
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

[RS6000] Use LIB2_SIDITI_CONV_FUNCS in place of ppc64-fp.c

2020-11-13 Thread Alan Modra via Gcc-patches
cb 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

obstack.h __PTR_ALIGN vs. ubsan

2021-09-01 Thread Alan Modra via Gcc-patches
A))) #ifndef __attribute_pure__ # if defined __GNUC_MINOR__ && __GNUC__ * 1000 + __GNUC_MINOR__ >= 2096 -- Alan Modra Australia Development Lab, IBM

Make opcodes configure depend on bfd configure

2021-11-12 Thread Alan Modra via Gcc-patches
stageautoprofile-bfd +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

Re: PowerPC64 ELFv2 -fpatchable-function-entry

2021-05-19 Thread Alan Modra via Gcc-patches
to contribute new gcc work. This one was just flushing some patches that I wrote a while ago. -- Alan Modra Australia Development Lab, IBM

Re: [POWER10] __morestack calls from pcrel code

2021-07-14 Thread Alan Modra via Gcc-patches
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 > >

Re: [PATCH 2/4 REVIEW] libtool.m4: fix nm BSD flag detection

2021-07-21 Thread Alan Modra via Gcc-patches
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

Re: [POWER10] __morestack calls from pcrel code

2021-07-21 Thread Alan Modra via Gcc-patches
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. > &

Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

2021-05-02 Thread Alan Modra via Gcc-patches
ial patch 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

Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

2021-05-03 Thread Alan Modra via Gcc-patches
less the C99 check 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

Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

2021-05-04 Thread Alan Modra via Gcc-patches
c/config/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 Mo

Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

2021-05-05 Thread Alan Modra via Gcc-patches
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 thi

PR98125, PowerPC64 -fpatchable-function-entry

2021-05-06 Thread Alan Modra via Gcc-patches
on on both 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/con

PowerPC64 ELFv1 -fpatchable-function-entry

2021-05-06 Thread Alan Modra via Gcc-patches
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

Revert "rs6000: Avoid -fpatchable-function-entry* regressions on powerpc64 be [PR98125]"

2021-05-06 Thread Alan Modra via Gcc-patches
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.

PowerPC64 ELFv2 -fpatchable-function-entry

2021-05-06 Thread Alan Modra via Gcc-patches
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 for

Re: PowerPC64 ELFv1 -fpatchable-function-entry

2021-05-18 Thread Alan Modra via Gcc-patches
ultimate_transparent_alias_target (&id); - 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

Re: PowerPC64 ELFv2 -fpatchable-function-entry

2021-05-18 Thread Alan Modra via Gcc-patches
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

Re: [RS6000] PR96493, powerpc local call linkage failure

2020-08-11 Thread Alan Modra via Gcc-patches
ire-effective-target power10_ok } */ /* Test local calls between pcrel and non-pcrel code. -- Alan Modra Australia Development Lab, IBM

Re: [RS6000] PR96493, powerpc local call linkage failure

2020-08-11 Thread Alan Modra via Gcc-patches
sing the power10_ok first time around on this test. -- Alan Modra Australia Development Lab, IBM

Re: [PATCH] rs6000: Support ELFv2 sibcall for indirect calls [PR96787]

2020-08-27 Thread Alan Modra via Gcc-patches
egressions. Is this okay for trunk? FWIW, looks fine to me. -- Alan Modra Australia Development Lab, IBM

Re: [PATCH] rs6000: Support ELFv2 sibcall for indirect calls [PR96787]

2020-08-27 Thread Alan Modra via Gcc-patches
_aix that Bill copied. So does emit_move_insn prevent the copy? I can't spot where, maybe I haven't looked hard enough. If emit_move_insn doesn't prevent it, then why create useless RTL that is only going to make work for optimisation passes that remove such nops? -- Alan Modra A

Re: [PATCH] rs6000: Support ELFv2 sibcall for indirect calls [PR96787]

2020-08-28 Thread Alan Modra via Gcc-patches
y generate dead code optimising cases that do not happen, making > the compiler bigger and slower, but more importantly, making the > compiler code harder to read? Uh, OK point 2 and followup 3 is persuasive. I should have thought of that myself, thanks. -- Alan Modra Australia Development Lab, IBM

ubsan: d-demangle.c:214 signed integer overflow

2020-09-03 Thread Alan Modra via Gcc-patches
6, the result -will not be a multiple of 26. */ - if ((*ret % 26) != 0) - return NULL; + val *= 26; if (mangled[0] >= 'a' && mangled[0] <= 'z') { - (*ret) += mangled[0] - 'a'; + val += mangled[0] - 'a'; + *ret = val; return mangled + 1; } - (*ret) += mangled[0] - 'A'; + val += mangled[0] - 'A'; mangled++; } -- Alan Modra Australia Development Lab, IBM

Re: ubsan: d-demangle.c:214 signed integer overflow

2020-09-03 Thread Alan Modra via Gcc-patches
and variables to "unsigned long", because it was clear from the code (and my understanding of name mangling) that the values were in fact always unsigned. I also changed "int" to "size_t" where appropriate, not that you need to handle strings larger than 2G in length but simply that size_t is the correct type to use with string functions, malloc, memcpy and so on. I decided to remove all those changes before posting as they were just tidies, I thought. -- Alan Modra Australia Development Lab, IBM

Re: ubsan: d-demangle.c:214 signed integer overflow

2020-09-04 Thread Alan Modra via Gcc-patches
return mangled; diff --git a/libiberty/testsuite/d-demangle-expected b/libiberty/testsuite/d-demangle-expected index e3f32e31d7..97bcdd5978 100644 --- a/libiberty/testsuite/d-demangle-expected +++ b/libiberty/testsuite/d-demangle-expected @@ -1140,6 +1140,14 @@ _D4test34__T3barVG3uw3_616263VG3wd3_646566Z1xi test.bar!("abc"w, "def"d).x # --format=dlang +_D4test21__T3funVwi4294967295Z3funFNaNbNiNfZv +test.fun!('\U').fun() +# +--format=dlang +_D4test21__T3funVwi4294967296Z3funFNaNbNiNfZv +_D4test21__T3funVwi4294967296Z3funFNaNbNiNfZv +# +--format=dlang _D6plugin8generateFiiZAya plugin.generate(int, int) # -- Alan Modra Australia Development Lab, IBM

Re: ubsan: d-demangle.c:214 signed integer overflow

2020-09-06 Thread Alan Modra via Gcc-patches
ssing then #define UINT_MAX ((unsigned) ~0) would be correct for K&R. > I'll leave it to your judgement on that though. > > Other than that, OK from me. Do I need an OK from Ian too? -- Alan Modra Australia Development Lab, IBM

Re: [PATCH] ppc64 check for incompatible setting of minimal-toc

2020-09-11 Thread Alan Modra via Gcc-patches
model=large with either of -mminimal-toc or -mno-minimal-toc, since the toc options really are specific to small model code. Why change that? -- Alan Modra Australia Development Lab, IBM

[RS6000] make PLT loads volatile

2020-03-11 Thread Alan Modra via Gcc-patches
quot;" "") - (match_operand:P 2 "symbol_ref_operand" "s") - (match_operand:P 3 "" "")] - UNSPEC_PLT_PCREL))] + (unspec_volatile:P [(match_operand:P 1 "" "") + (match_operand:P 2 "symbol_ref_operand" "s") + (match_operand:P 3 "" "")] + UNSPECV_PLT_PCREL))] "HAVE_AS_PLTSEQ && TARGET_ELF && rs6000_pcrel_p (cfun)" { -- Alan Modra Australia Development Lab, IBM

Re: [RS6000] make PLT loads volatile

2020-03-12 Thread Alan Modra via Gcc-patches
On Thu, Mar 12, 2020 at 11:57:17AM -0500, Segher Boessenkool wrote: > Hi! > > On Thu, Mar 12, 2020 at 01:18:50PM +1030, Alan Modra wrote: > > With lazy PLT resolution the first load of a PLT entry may be a value > > pointing at a resolver stub. gcc's loop processing

Re: [RS6000] make PLT loads volatile

2020-03-13 Thread Alan Modra via Gcc-patches
On Fri, Mar 13, 2020 at 10:40:38AM -0500, Segher Boessenkool wrote: > Hi! > > On Fri, Mar 13, 2020 at 10:06:01AM +1030, Alan Modra wrote: > > On Thu, Mar 12, 2020 at 11:57:17AM -0500, Segher Boessenkool wrote: > > > On Thu, Mar 12, 2020 at 01:18:50PM +1030, Alan Modra wrot

[RS6000] PR94145, make PLT loads volatile

2020-03-22 Thread Alan Modra via Gcc-patches
quot; "=r") - (unspec:P [(match_operand:P 1 "" "") - (match_operand:P 2 "symbol_ref_operand" "s") - (match_operand:P 3 "" "")] - UNSPEC_PLT_PCREL))] + (unspec_vola

[RS6000] PR96493, powerpc local call linkage failure

2020-08-06 Thread Alan Modra via Gcc-patches
ubs. */ + +int one = 1; + +int __attribute__ ((target("cpu=power8"),noclone,noinline)) +p8_func (int x) +{ + return x - one; +} + +int __attribute__ ((target("cpu=power10"),noclone,noinline)) +p10_func (int x) +{ + return p8_func (x); +} + +int +main (void) +{ + return p10_func (1); +} -- Alan Modra Australia Development Lab, IBM

Re: [RS6000] PR96493, powerpc local call linkage failure

2020-08-06 Thread Alan Modra via Gcc-patches
this requires ELFv2 anyway? Or, what > does it need here? It isn't clear to me. But you don't want a pseudo- > POWER3 with ELFv2 :-) What I was trying to say by using cpu=powerpc64 is that this test has minimal requirements on the required cpu level to run the test. That's al

[RS6000] Put call cookie back in AIX/ELFv2 call patterns

2020-03-27 Thread Alan Modra via Gcc-patches
h the ELFv2 ABI. ;; Operand0 is the addresss of the function to call -;; Operand2 is the offset of the stack location holding the current TOC pointer +;; Operand3 is the offset of the stack location holding the current TOC pointer (define_insn "*call_indirect_elfv2" [(call (mem:SI (match_opera

Re: [PATCH] rs6000: Don't split constant oprator when add, move to temp register for future optimization

2020-04-03 Thread Alan Modra via Gcc-patches
mit code that loads constants from memory without following optimisation passes converting the loads from memory to those long sequences of dependent instructions. -- Alan Modra Australia Development Lab, IBM

Re: [PATCH] rs6000: Don't split constant oprator when add, move to temp register for future optimization

2020-04-03 Thread Alan Modra via Gcc-patches
On Fri, Apr 03, 2020 at 04:11:32PM -0500, Segher Boessenkool wrote: > On Fri, Apr 03, 2020 at 10:43:49PM +1030, Alan Modra wrote: > > Segher probably meant the part I'm working on and haven't posted yet, > > fixing lots of problems with rs6000_rtx_costs. > > I

set_rtx_cost used wrongly, should be set_src_cost

2020-04-13 Thread Alan Modra via Gcc-patches
N_INT (-m)), speed_p); + cost_diff = set_src_cost (gen_rtx_PLUS (word_mode, reg, + GEN_INT (-m)), + word_mode, speed_p); for (i = 0; i < count; i++) { rtx r = immed_wide_int_const (test[i].mask, word

Re: [PATCH toplevel] libctf: new testsuite

2021-01-05 Thread Alan Modra via Gcc-patches
hanges too. I could 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

Re: [PATCH] binuitils: Check if AR is usable for LTO build

2021-01-11 Thread Alan Modra via Gcc-patches
n > RANLIB_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

Re: [PATCH 0/8] [RS6000] rs6000_rtx_costs V2

2021-01-11 Thread Alan Modra via Gcc-patches
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] rs6

Re: [PATCH 0/2] Check if AR works with --plugin and rc

2021-01-11 Thread Alan Modra via Gcc-patches
email. -- Alan Modra Australia Development Lab, IBM

Re: [PATCH 1/2] GCC: Check if AR works with --plugin and rc

2021-01-11 Thread Alan Modra via Gcc-patches
test -n "$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

Re: V2 [PATCH 1/2] GCC: Check if AR works with --plugin and rc

2021-01-11 Thread Alan Modra via Gcc-patches
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

Re: [PATCH] binuitils: Check if AR is usable for LTO build

2021-01-11 Thread Alan Modra via Gcc-patches
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: > > >

Re: [PATCH 0/8] [RS6000] rs6000_rtx_costs V2

2020-12-05 Thread Alan Modra via Gcc-patches
t testcases for power10 instructions V3 https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557587.html -- Alan Modra Australia Development Lab, IBM

Re: testsuite: Adjust target requirements for sad-vectorize and signbit

2020-12-05 Thread Alan Modra via Gcc-patches
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

Re: [PATCH, powerpc] testsuite update tests for powerpc power10 target codegen.

2020-12-08 Thread Alan Modra via Gcc-patches
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

Re: [PATCH] calls.c:can_implement_as_sibling_call_p REG_PARM_STACK_SPACE check

2020-10-12 Thread Alan Modra via Gcc-patches
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

Re: [PATCH 2/8] [RS6000] rs6000_rtx_costs for AND

2020-10-20 Thread Alan Modra via Gcc-patches
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 >

Re: [PATCH 2/8] [RS6000] rs6000_rtx_costs for AND

2020-10-21 Thread Alan Modra via Gcc-patches
; 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

[RS6000] VSX_MM_SUFFIX

2020-10-21 Thread Alan Modra via Gcc-patches
ec:VSX_MM [(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

[RS6000] Power10 vec-splati-runnable multiple test failures

2020-10-21 Thread Alan Modra via Gcc-patches
e, expected_vresult_d[%i] = %e\n", i, vresult_d[i], i, expected_vresult_d[i]); #else -abort(); +; #endif } -- Alan Modra Australia Development Lab, IBM

[RS6000] Non-pcrel tests when power10

2020-10-21 Thread Alan Modra via Gcc-patches
hrink-wrap.c +++ b/gcc/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

[RS6000] dimode_off.c test

2020-10-22 Thread Alan Modra via Gcc-patches
ong long y) { *(long long *) (x + 32766) = y; } -- Alan Modra Australia Development Lab, IBM

[RS6000] Link power10 testcases

2020-10-22 Thread Alan Modra via Gcc-patches
-runnable.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 power

[RS6000] Adjust testcases for power10 instructions

2020-10-22 Thread Alan Modra via Gcc-patches
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

Re: [PATCH] calls.c:can_implement_as_sibling_call_p REG_PARM_STACK_SPACE check

2020-10-22 Thread Alan Modra via Gcc-patches
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

Re: [RS6000] Adjust testcases for power10 instructions

2020-10-22 Thread Alan Modra via Gcc-patches
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

Re: [RS6000] VSX_MM_SUFFIX

2020-10-22 Thread Alan Modra via Gcc-patches
uot; tests with "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

Re: [RS6000] Power10 vec-splati-runnable multiple test failures

2020-10-22 Thread Alan Modra via Gcc-patches
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

Re: [RS6000] Adjust testcases for power10 instructions

2020-10-22 Thread Alan Modra via Gcc-patches
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

[RS6000] altivec style lvx/stvx addresses vs power10

2020-10-22 Thread Alan Modra via Gcc-patches
registers_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

[RS6000] Power10 ICE running gcc.target/powerpc/ppc-ne0-1.c

2020-10-23 Thread Alan Modra via Gcc-patches
(TARGET_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

Re: [RS6000] Adjust testcases for power10 instructions

2020-10-23 Thread Alan Modra via Gcc-patches
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

Re: [PATCH 2/8] [RS6000] rs6000_rtx_costs for AND

2020-10-23 Thread Alan Modra via Gcc-patches
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, >

Re: [RS6000] altivec style lvx/stvx addresses vs power10

2020-10-23 Thread Alan Modra via Gcc-patches
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 ]) > >

Re: [RS6000] VSX_MM_SUFFIX

2020-10-23 Thread Alan Modra via Gcc-patches
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: >

Re: [RS6000] VSX_MM_SUFFIX

2020-10-24 Thread Alan Modra via Gcc-patches
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

[RS6000] Tests that use int128_t and -m32

2020-10-25 Thread Alan Modra via Gcc-patches
-target { int128 && 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

[RS6000] Unsupported test options for -m32

2020-10-25 Thread Alan Modra via Gcc-patches
get { lp64 && 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

[RS6000] Remove -mpcrel from tests

2020-10-25 Thread Alan Modra via Gcc-patches
*/ /* { dg-require-effective-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

[RS6000] biarch test fail

2020-10-25 Thread Alan Modra via Gcc-patches
2. */ + 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

Re: [RS6000] Tests that use int128_t and -m32

2020-10-26 Thread Alan Modra via Gcc-patches
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

Re: [RS6000] Non-pcrel tests when power10

2020-10-26 Thread Alan Modra via Gcc-patches
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/

Re: [RS6000] Tests that use int128_t and -m32

2020-10-26 Thread Alan Modra via Gcc-patches
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

Re: [RS6000] Unsupported test options for -m32

2020-10-26 Thread Alan Modra via Gcc-patches
get/powerpc/swaps-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

[RS6000] Adjust testcases for power10 instructions V2

2020-10-26 Thread Alan Modra via Gcc-patches
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

[RS6000] Separate dg-require-effective-target options

2020-10-26 Thread Alan Modra via Gcc-patches
{ 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

[RS6000] dg-do !compile and scan-assembler

2020-10-27 Thread Alan Modra via Gcc-patches
>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

[RS6000] power10 scan-assembler tests

2020-10-27 Thread Alan Modra via Gcc-patches
@ -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

Re: [RS6000] dg-do !compile and scan-assembler

2020-10-27 Thread Alan Modra via Gcc-patches
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. >

Re: testsuite: Enable and adjust powerpc fold-vec-extract/insert testcases

2020-10-28 Thread Alan Modra via Gcc-patches
sembler-times {\mlxv\M} 8 { target ilp32 } } } */ /* { dg-final { scan-assembler-times {\mlvewx\M} 4 { target ilp32 } } } */ -- Alan Modra Australia Development Lab, IBM

Re: [RS6000] Do not define builtins that overload disabled builtins

2020-10-28 Thread Alan Modra via Gcc-patches
in_byte_in_set (b, set_members); /* { dg-warning "implicit declaration of function" } */ } -- Alan Modra Australia Development Lab, IBM

[RS6000] float128-type-2.c unsupported

2020-10-28 Thread Alan Modra via Gcc-patches
>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

[RS6000] Don't be too clever with dg-do run and dg-do compile

2020-10-28 Thread Alan Modra via Gcc-patches
element) */ -/* { 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

Re: [RS6000] Don't be too clever with dg-do run and dg-do compile

2020-10-28 Thread Alan Modra via Gcc-patches
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 > >

<    5   6   7   8   9   10   11   >