Re: [PATCH] rs6000: Call flow implementation for PC-relative addressing

s okay for trunk? Thanks, Bill On 5/24/19 9:06 AM, Bill Schmidt wrote: > New test case ICEs, so consider this withdrawn.  Sorry again about this. > > Bill > > On 5/23/19 9:17 PM, Bill Schmidt wrote: >> Hm, I got ahead of myself on this one.  I haven't done the regstrap

[PATCH] rs6000: Add undocumented switch -mprefixed-addr

this okay for trunk? Thanks, Bill 2019-05-28 Bill Schmidt Michael Meissner * rs6000-cpus.def (OTHER_FUSION_MASKS): New #define. (ISA_FUTURE_MASKS_SERVER): Add OPTION_MASK_PREFIXED_ADDR. Mask off OTHER_FUSION_MASKS. (OTHER_FUTURE_MASKS): Add

Re: [PATCH] rs6000: Call flow implementation for PC-relative addressing

On 5/29/19 7:40 AM, Segher Boessenkool wrote: > Hi Bill, > > On Thu, May 23, 2019 at 09:11:44PM -0500, Bill Schmidt wrote: >> (1) When a function uses PC-relative code generation, all direct calls >> (other than >> sibcalls) that the function makes to local or ext

[PATCH] rs6000: Add eI constraint for 34-bit constants

Hi, This short patch introduces the eI constraint. It also adds the SIGNED_16BIT_OFFSET_P convenience macro that will be used in subsequent patches. Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions. Is this okay for trunk? Thanks, Bill 2019-05-29 Bill Schmidt

Re: [PATCH] rs6000: Add undocumented switch -mprefixed-addr

On 5/29/19 8:16 AM, Segher Boessenkool wrote: > Hi! > > On Wed, May 29, 2019 at 07:42:38AM -0500, Bill Schmidt wrote: >> * rs6000-cpus.def (OTHER_FUSION_MASKS): New #define. >> (ISA_FUTURE_MASKS_SERVER): Add OPTION_MASK_PREFIXED_ADDR. Mask off >> OTHER

[PATCH v2] rs6000: Add undocumented switch -mprefixed-addr

ested on powerpc64le-unknown-linux-gnu with no regressions. Is this version okay for trunk? Thanks! Bill 2019-05-29 Bill Schmidt Michael Meissner * rs6000-cpus.def (OTHER_FUSION_MASKS): New #define. (ISA_3_0_MASKS_SERVER): Mask off OTHER_FUSION_MASKS.

[PATCH] rs6000: Add basic support for prefixed and PC-relative addresses

Hi, This patch adds basic infrastructure for prefixed and PC-relative addresses, including new predicates and functions to detect when they apply. Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions. Is this okay for trunk? Thanks, Bill 2019-05-29 Bill Schmidt

[PATCH] rs6000: Add target supports for "future" system

Hi, This patch from Mike Meissner adds procs to target-supports.exp to support -mcpu=future. Tested in conjunction with the next patch (test cases) with no problems. Is this okay for trunk? Thanks, Bill 2019-05-29 Michael Meissner * lib/target-supports.exp (check_powerpc_future_hw

[PATCH] rs6000: Update test cases to use powerpc_future_ok

Hi, This patch updates test cases to use the new powerpc_future_ok effective target. Tested on powerpc64le-unknown-linux-gnu with no problems. Is this okay for trunk? Thanks, Bill 2019-05-29 Bill Schmidt Michael Meissner * gcc.target/powerpc/cpu-future.c: Require

Re: [PATCH] rs6000: Add basic support for prefixed and PC-relative addresses

On 5/30/19 2:20 PM, Segher Boessenkool wrote: > On Wed, May 29, 2019 at 10:49:35PM -0500, Bill Schmidt wrote: >> * config/rs6000/predicates.md (pcrel_address): New >> define_predicate. > Please put that on one line? OK.  Emacs in ChangeLog and Fill modes seems to

[PATCH] rs6000: Fix PR78263: Don't #define vector, pixel, bool for C++ with strict ANSI

s is the first target-specific C++ test for Power, so I created the new g++.target/powerpc directory and added powerpc.exp there, based on the existing aarch64.exp in a sister directory. Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions. Is this okay for trunk? Thanks, Bill

Re: [PATCH v4 2/3] Add predict_doloop_p target hook

On 6/14/19 4:53 PM, Segher Boessenkool wrote: > Hi Kewen, > > On Thu, Jun 13, 2019 at 01:50:05PM +0800, Kewen.Lin wrote: >> Comparing with the previous version, I dropped the checks >> on costly niter and invalid stmt scanning. As Richard's >> suggestion, keep this as simple as possible, refine

[PATCH, rs6000] Clarify when typedef names can be used with AltiVec vector types

Hi, We recently discovered some incorrect documentation about this topic and agreed it should be changed. This is my attempt to clarify it. Built and verified on powerpc64le-linux-gnu. Is this ok for trunk? Thanks, Bill 2018-12-17 Bill Schmidt * doc/extend.texi (PowerPC Altivec

Re: [PATCH, rs6000] Clarify when typedef names can be used with AltiVec vector types

On 12/18/18 4:33 AM, Ulrich Weigand wrote: > Bill Schmidt wrote: > >> +@item >> +When using vector in keyword-and-predefine mode; for example, >> + >> +@smallexample >> +/* With -maltivec only: */ > This is a bit confusing (at least to me). What does &

Re: [PATCH, rs6000] Clarify when typedef names can be used with AltiVec vector types

On 12/18/18 7:43 AM, Ulrich Weigand wrote: > Bill Schmidt wrote: > >> +@item >> +When using @code{vector} in keyword-and-predefine mode; for example, >> + >> +@smallexample >> +typedef signed short int16; >> +vector int16 data; >> +@end smallexamp

Re: [patch] Fix minor SLSR pessimization

On 8/2/19 8:15 AM, Eric Botcazou wrote: > Hi, > > an user reported that, for pairs of consecutive memory accesses, the SLSR > pass > can slightly pessimize the generated code at -O2 on the x86 architecture: > > struct x > { > int a[16]; > int b[16]; > }; > > void > set (struct x *p, unsigned

Re: [PATCH], Patch #1 replacement (fix issues with future TLS patches)

Hi Mike, just a couple points from me... On 8/15/19 4:19 PM, Michael Meissner wrote: > Index: gcc/config/rs6000/rs6000.c > === > --- gcc/config/rs6000/rs6000.c(revision 274172) > +++ gcc/config/rs6000/rs6000.c(workin

Re: [PATCH], Patch #3 of 10, Add prefixed addressing support

On 8/14/19 5:06 PM, Michael Meissner wrote: > This patch adds prefixed memory support to all offsettable instructions. > > Unlike previous versions of the patch, this patch combines all of the > modifications for addressing to one patch. Previously, I had 3 separate > patches (one for PADDI, one f

Re: [PATCH] Fix PR91790

On 9/19/19 1:34 PM, Segher Boessenkool wrote: Hi! On Tue, Sep 17, 2019 at 09:45:54AM +0200, Richard Biener wrote: The following fixes an old vectorizer issue with realignment support (thus only powerpc is affected) and BB vectorization. The realignment token is set up from the wrong data-ref

[PATCH] Fix PR87473 (SLSR ICE on hidden basis)

ith no regressions. I've added the test case from the bugzilla to the torture tests. Is this okay for trunk, and after a suitable period, to GCC 7 and 8 also? Thanks! Bill [gcc] 2018-10-12 Bill Schmidt PR tree-optimization/87473 * gimple-ssa-strength-reduction.c (record

[PATCH, rs6000] Don't use __vector __m64 for compatibility reasons

64le-linux-gnu with no regressions. Is this okay for trunk? Thanks! Bill 2018-10-19 Bill Schmidt Jinsong Ji * config/rs6000/emmintrin.h (_mm_movemask_pd): Replace __vector __m64 with __vector unsigned long long for compatibility. (_mm_movemask_epi8)

[PATCH, rs6000] Use unaligned vector types for some pointer casts

the same type. Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this okay for trunk? (I also cleaned up a badly formatted comment in the neighborhood.) Thanks, Bill 2018-10-19 Bill Schmidt Jinsong Ji * config/rs6000/emmintrin.h (_MM_SHUFFLE2

Re: [PATCH, rs6000] Use unaligned vector types for some pointer casts

On 10/20/18 10:53 AM, Segher Boessenkool wrote: > Hi! > > On Fri, Oct 19, 2018 at 04:27:27PM -0500, Bill Schmidt wrote: >> The x86 intrinsic compatibility headers contain a couple of instances of >> undefined behavior where a cast to an aligned type is used when that >>

Re: [PATCH, rs6000] Use unaligned vector types for some pointer casts

Just to follow up... On 10/21/18 6:13 PM, Bill Schmidt wrote: > On 10/20/18 10:53 AM, Segher Boessenkool wrote: >> Hi! >> >> On Fri, Oct 19, 2018 at 04:27:27PM -0500, Bill Schmidt wrote: >>> The x86 intrinsic compatibility headers contain a couple of instances of

[PATCH, rs6000] Use explicit casts for vec_sel argument 3 in intrinsic headers

For compatibility, cast the third parameter correctly in the source code. Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this okay for trunk? Thanks, Bill 2018-10-22 Bill Schmidt Jinsong Ji * config/rs6000/emmintrin.h (_mm_sll_epi64): Expli

[PATCH, rs6000] Don't use deprecated __vector long in intrinsic compatibility headers

okay for trunk? Thanks, Bill 2018-10-22 Bill Schmidt Jinsong Ji * config/rs6000/emmintrin.h (_mm_cvtpd_epi32): Change deprecated __vector long to __vector long long. (_mm_cvtpd_ps): Likewise. (_mm_cvttpd_epi32): Likewise. (_mm_cvtpi32_pd

[PATCH, rs6000, v2] Fix uses of vec_sel in intrinsic headers

hanks! Bill 2018-10-24 Bill Schmidt Jinsong Ji * config/rs6000/emmintrin.h (_mm_sll_epi64): Remove wrong cast. * config/rs6000/xmmintrin.h (_mm_min_ps): Change m's type to __vector __bool int. Use vec_cmpgt in preference to deprecated

[PATCH, rs6000] Replace comparison operators with vec_cmp* in intrinsic compatibility headers

functions. Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this okay for trunk? Thanks, Bill 2018-10-24 Bill Schmidt Jinsong Ji * gcc/config/rs6000/emmintrin.h (_mm_sll_epi16): Replace comparison operators with vec_cmp* for compatibility

[PATCH, rs6000] Don't use deprecated vector shift instructions

regressions. Is this okay for trunk? Thanks, Bill 2018-10-24 Bill Schmidt Jinsong Ji * config/rs6000/emmintrin.h (_mm_slli_epi16): Replace deprecated function with vec_sl. (_mm_slli_epi32): Likewise. (_mm_slli_epi64): Likewise

Re: [PATCH, rs6000, v2] Fix uses of vec_sel in intrinsic headers

On 10/25/18 12:08 PM, Segher Boessenkool wrote: > On Wed, Oct 24, 2018 at 09:25:25AM -0500, Bill Schmidt wrote: >> This patch addresses Segher's findings, and also replaces usages of the >> deprecated function vec_vcmpgtfp with the equivalent vec_cmpgt. >> Bootstrapped

[PATCH, rs6000] Intrinsic compatibility tests should not pass just because DEBUG is set

intentional oddity). A lot of these tests are also miserably formatted, so I took the liberty of cleaning that up while I was in here. Tested on powerpc64le-linux-gnu with no failures. Is this ok for trunk, and potential backport to 8? Thanks! Bill 2018-10-25 Bill Schmidt Jinsong

[PATCH, committed] Backport PR87473 fix to GCC 8

Committed the backport as follows: [gcc] 2018-10-26 Bill Schmidt Backport from mainline 2018-10-19 Bill Schmidt PR tree-optimization/87473 * gimple-ssa-strength-reduction.c (record_phi_increments_1): For phi arguments identical to the base

Re: [PATCH v2, rs6000 4/4] Add compatible implementations of x86 SSSE3 intrinsics

On 10/25/18 2:08 PM, Paul Clarke wrote: > This is part 2/2 for contributing PPC64LE support for X86 SSE3 > instrisics. This patch includes testsuite/gcc.target tests for the > intrinsics defined in pmmintrin.h, copied from gcc.target/i386. > > Bootstrapped and tested on Linux POWER8 LE, POWER8 BE (

[PATCH, committed] Backport PR87473 fix to GCC 7

Committed the backport as follows (some slight changes between versions were required): [gcc] 2018-10-26 Bill Schmidt Backport from mainline 2018-10-19 Bill Schmidt PR tree-optimization/87473 * gimple-ssa-strength-reduction.c (record_phi_increments): For

[PATCH, rs6000] Fix constraints issue in _mm_cvtss_si{32,64}

tion. Installed and tested on powerpc64le-linux-gnu with no regressions. Is this okay for trunk? Thanks, Bill 2018-11-08 Bill Schmidt Jinsong Ji * config/rs6000/xmmintrin.h (_mm_cvtss_si32): Fix incorrect constraints by introducing a new temporary. (_mm_cvtss

Re: [PATCH 2/6] [RS6000] rs6000_output_indirect_call

On 11/6/18 11:37 PM, Alan Modra wrote: > Like the last patch for external calls, now handle most assembly code > for indirect calls in one place. The patch also merges some insns, > correcting some !rs6000_speculate_indirect_jumps cases branching to > LR, which don't require a speculation barrier.

Re: [RFA][tree-optimization/90883] Improve DSE to handle redundant calls

Looks like this patch breaks bootstrap. /home3/wschmidt/gcc/gcc-mainline-base/gcc/tree-ssa-dse.c: In function 'void dse\ _optimize_redundant_stores(gimple*)': /home3/wschmidt/gcc/gcc-mainline-base/gcc/tree-ssa-dse.c:649:46: error: ISO C++\  forbids converting a string constant to 'char*' [-Werror=

[PATCH] rs6000: Enable -fvariable-expansion-in-unroller by default

s. Is this OK for trunk? Thanks! Bill 2019-06-27 Bill Schmidt * config/rs6000/rs6000.c (rs6000_option_override_internal): Enable -fvariable-expansion-in-unroller by default. Index: gcc/config/rs6000/rs6000.c === --

Re: [PATCH] rs6000: Enable -fvariable-expansion-in-unroller by default

On 6/27/19 6:45 AM, Segher Boessenkool wrote: > On Thu, Jun 27, 2019 at 11:33:45AM +0200, Richard Biener wrote: >> On Thu, Jun 27, 2019 at 5:23 AM Bill Schmidt wrote: >>> We've done some experimenting and realized that the subject option almost >>> always provid

Re: [PATCH] PowerPC Prefixed Memory, Patch #3, Update predicates

On 6/28/19 8:20 AM, Segher Boessenkool wrote: > Hi Mike, > > On Thu, Jun 27, 2019 at 08:12:35PM -0400, Michael Meissner wrote: >> + return (TARGET_CMODEL == CMODEL_MEDIUM && SYMBOL_REF_P (op) >> + && SYMBOL_REF_LOCAL_P (op)); > Please break the line before that first && as well? > >> +(define

Re: [PATCH v2] [rs6000] Add _mm_blend_epi16 and _mm_blendv_epi8

On 7/22/19 12:58 AM, Segher Boessenkool wrote: > On Sun, Jul 21, 2019 at 05:22:19PM -0500, Paul Clarke wrote: >> Add compatibility implementations of _mm_blend_epi16 and _mm_blendv_epi8 >> intrinsics. >> >> Respective test cases are copied almost verbatim (minor changes to >> the dejagnu head lines

Re: [PATCH] rs6000: Fix PR 88100, range check for vec_splat_{su}{8,16,32}

On 2/19/19 8:11 AM, Segher Boessenkool wrote: > Hi! > > On Tue, Feb 19, 2019 at 03:38:56AM -0600, Li Jia He wrote: >> GCC revision 259524 implemented range check for the vec_splat_{su}{8,16,32} >> builtins. However, as a consequence of the implementation, the range check >> is not done correctly f

Re: [PATCH] rs6000: Fix PR 88100, range check for vec_splat_{su}{8,16,32}

On 2/20/19 8:36 AM, Jakub Jelinek wrote: > On Wed, Feb 20, 2019 at 08:34:41AM -0600, Segher Boessenkool wrote: >> [ Don't top-post please ] >> >> On Wed, Feb 20, 2019 at 12:35:37PM +0800, Li Jia He wrote: I believe you will also want to get permission to backport this to GCC 8. It looks l

[PATCH] rs6000: Fix lost ud chains in swap optimization

-linux-gnu with no regressions. I've not included a test case because the problem tends to get lost in reduction, and may shift over time anyway. Is this okay for trunk, and eventual backport to 8 and 7? Thanks! Bill 2019-03-07 Bill Schmidt * config/rs6000/rs6000-p8s

Re: [PATCH] rs6000: Fix lost ud chains in swap optimization

On 3/8/19 4:40 AM, Richard Biener wrote: > On Fri, Mar 8, 2019 at 1:34 AM Bill Schmidt wrote: >> Hi, >> >> We recently discovered a problem in swap optimization where the du- and >> ud-chains >> were getting corrupted after a preliminary modification phase and

Re: [PATCH V2] PR88497 - Extend reassoc for vector bit_field_ref

On 3/12/19 7:57 AM, Kewen.Lin wrote: > Hi, > > As the comments from Richard and Segher (Thanks!), I've made some > changes by adding some checks and extensions. > *) Check whether vector type available on target machine, > *) Check whether vector operation available on target machine, > *)

Re: [PATCH V2] PR88497 - Extend reassoc for vector bit_field_ref

On 3/12/19 9:29 AM, Bill Schmidt wrote: > On 3/12/19 7:57 AM, Kewen.Lin wrote: >> Hi, >> >> As the comments from Richard and Segher (Thanks!), I've made some >> changes by adding some checks and extensions. >> *) Check whether vector type available on

[PATCH] rs6000: Fix typo in mmintrin.h

-linux-gnu with no regressions. Is this ok for trunk, and backport to GCC 8? Thanks! Bill [gcc] 2019-03-21 Bill Schmidt * config/rs6000/mmintrin.h (_mm_sub_pi32): Fix typo. [gcc/testsuite] 2019-03-21 Bill Schmidt * gcc.target/powerpc/mmx-psubd-2.c: Test _m_psubd.

[PATCH, committed] Fix PR89834

. Tested on powerpc64le-unknown-linux-gnu (P9) and powerpc64-unknown-linux-gnu (P7), correct behavior verified. Committed as requested in the bugzilla (r269978). Thanks, Bill 2019-03-27 Bill Schmidt * gcc.dg/vect/pr81740-2.c: Require vect_hw_misalign. Index: gcc/testsuite/gcc.dg

[doc, committed] Remove stale reference to FOR_EACH_LOOP_BREAK

Hi, We removed FOR_EACH_LOOP_BREAK from the compiler six years ago, but it still shows up in the internals manual. Fix that. Tested, committed as obvious. Thanks, Bill 2019-05-09 Bill Schmidt * doc/loop.texi: Remove reference to FOR_EACH_LOOP_BREAK. Index: gcc/doc/loop.texi

Re: [PATCH v2 2/3] Add predict_doloop_p target hook

On 5/14/19 2:13 PM, Jeff Law wrote: > On 5/13/19 9:09 PM, li...@linux.ibm.com wrote: >> From: Kewen Lin >> >> Previous version link for background: >> https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00912.html >> >> This hook is to predict whether one loop in gimple will >> be transformed to low-ove

Re: [PATCH PR57534]Support strength reduction for MEM_REF in slur

Thanks, Bin and Richard -- I am out of the office until Tuesday, so will review when I get back. Bin, please CC me on SLSR patches as otherwise I might miss them. Thanks! Bill On 5/16/19 6:37 AM, Richard Biener wrote: > On Wed, May 15, 2019 at 6:30 AM bin.cheng wrote: >> Hi, >> As noted in PR

Re: [PATCH, rs6000, testsuite] Fix PR87306

I can't approve the patch, but I agree this is the right fix. Bill On 1/16/19 3:29 AM, Kewen.Lin wrote: > Hi, > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87306, it's older POWER > hardware specific test case issue. On POWER7 and earlier, we implicitly > set flag -mno-allow-movmisalign whi

[PATCH] rs6000: Fix PR87604

-unknown-linux-gnu with no regressions. The failing testcase now passes. Is this okay for trunk, and eventually for backports to all supported releases? Thanks, Bill 2019-01-22 Jakub Jelinek Bill Schmidt * config/rs6000/vsx.md (*vsx_reduc__v2df_scalar): Disable for

[PATCH, committed] Fix SLSR portion of PR89008

tested on powerpc64le-unknown-linux-gnu with no regressions. Tested on an older revision where the bug was observable and found to fix the problem. Committed, backports pending. Thanks, Bill 2018-01-31 Bill Schmidt PR tree-optimization/89008 * gimple-ssa-strength-r

[PATCH] rs6000: Vector shift-right should honor modulo semantics

and for GCC 8.3 if there is no fallout by the end of the week? Thanks, Bill [gcc] 2019-02-08 Bill Schmidt * config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Shift-right and shift-left vector built-ins need to include a TRUNC_MOD_EXPR for correct semantics. Also,

Re: [PATCH] rs6000: Vector shift-right should honor modulo semantics

On 2/10/19 4:05 PM, Segher Boessenkool wrote: > Hi Bill, > > On Sun, Feb 10, 2019 at 10:10:02AM -0600, Bill Schmidt wrote: >> I've added executable tests for both shift-right algebraic and shift-right >> logical. >> Both fail prior to applying the patch, and wor

Re: [PATCH] rs6000: Vector shift-right should honor modulo semantics

On 2/10/19 8:42 PM, Bill Schmidt wrote: > On 2/10/19 4:05 PM, Segher Boessenkool wrote: >> Hi Bill, >> >> On Sun, Feb 10, 2019 at 10:10:02AM -0600, Bill Schmidt wrote: >>> I've added executable tests for both shift-right algebraic and shift-right >>>

Re: [PATCH] rs6000: Vector shift-right should honor modulo semantics

On 2/11/19 6:43 AM, Segher Boessenkool wrote: > On Sun, Feb 10, 2019 at 08:42:42PM -0600, Bill Schmidt wrote: >> On 2/10/19 4:05 PM, Segher Boessenkool wrote: >>> On Sun, Feb 10, 2019 at 10:10:02AM -0600, Bill Schmidt wrote: >>>> I've added executable tests for b

[PATCH, v2] rs6000: Vector shift-right should honor modulo semantics

for trunk, and for GCC 8.3 if there is no fallout by the end of the week? Thanks, Bill [gcc] 2019-02-11 Bill Schmidt * config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Shift-right and shift-left vector built-ins need to include a TRUNC_MOD_EXPR for correct semant

Re: [PATCH] rs6000: Vector shift-right should honor modulo semantics

On 2/11/19 8:11 AM, Segher Boessenkool wrote: > On Mon, Feb 11, 2019 at 07:17:16AM -0600, Bill Schmidt wrote: >> At -O0 (if I hand-inline everything myself to avoid errors), we scalarize >> the modulo/masking operation into a rldicl for each doubleword. I really >> don'

Re: [PATCH, v2] rs6000: Vector shift-right should honor modulo semantics

On 2/11/19 10:01 AM, Segher Boessenkool wrote: > Hi Bill, > > On Mon, Feb 11, 2019 at 07:36:11AM -0600, Bill Schmidt wrote: >> 2019-02-11 Bill Schmidt >> >> * config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Shift-right >> and shift-left v

[PATCH] rs6000: new vec-s*d-modulo.c tests should require p8vector_hw

behavior. Is this okay for trunk? Thanks, Bill 2018-01-11 Bill Schmidt * gcc.target/powerpc/vec-sld-modulo.c: Require p8vector_hw. * gcc.target/powerpc/vec-srad-modulo.c: Likewise. * gcc.target/powerpc/vec-srd-modulo.c: Likewise. Index: gcc/testsuite/gcc.target

Re: [PATCH, rs6000] Fix vec_construct vectorization cost to be somewhat more accurate

/vect/slp-4[35].c with the cost model enabled, and the results are sensible with these changes. SPEC results were all in the noise range. Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions. Ok for trunk? Thanks, Bill 2016-08-10 Bill Schmidt * config/r

[PATCH, rs6000] Fix PR72863 (swap optimization misses swaps generated from intrinsics)

5 branches after some burn-in time. I do not plan to rush this into 6.2; we'll have to wait for 6.3 as this is only a performance issue, albeit an important one. Thanks, Bill [gcc] 2016-08-11 Bill Schmidt PR target/72863 * vsx.md (vsx_load_): For P8LE, emit swaps

[PATCH, preapproved] Disable DF_VERIFY_SCHEDULED at end of df_verify (PR72855)

th no regressions. Preapproved, committed. Thanks, Bill 2016-08-11 Richard Biener Bill Schmidt PR rtl-optimization/72855 * df-core.c (df_verify): Turn off DF_VERIFY_SCHEDULED at end. Index: gcc/df-c

[PATCH, rs6000] Fix PR72827 (ada bootstrap failure)

c64le-unknown-linux-gnu with the usual languages plus ada, with no regressions. Gnattools now builds properly during bootstrap. Is this ok for trunk, and eventually for backport to the 5 and 6 branches? Thanks, Bill 2016-08-30 Bill Schmidt PR target/72827 * config/rs6000/rs6

Re: [PATCH, rs6000] Fix PR72827 (ada bootstrap failure)

On 8/31/16 1:19 AM, Segher Boessenkool wrote: > Hi Bill, > > On Tue, Aug 30, 2016 at 08:23:46PM -0500, Bill Schmidt wrote: >> The ada bootstrap failure reported in >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827 >> occurs because of a latent bug in the power

Re: [PATCH, rs6000] Fix PR72827 (ada bootstrap failure)

> On Aug 31, 2016, at 10:31 AM, Eric Botcazou wrote: > >> I'm not sure I'm the right person to do that, as I don't really have any >> familiarity with the DSE code. I can't even prove to myself that this code >> is alloca-safe; it doesn't look like it. > > No FUD, please ;-) The code is alloc

Re: [PATCH, rs6000] Fix PR72827 (ada bootstrap failure)

> On Aug 31, 2016, at 9:00 AM, Bill Schmidt wrote: > > > On 8/31/16 1:19 AM, Segher Boessenkool wrote: >>> >> If (say) base=r1 offset=r0 this will now adjust r1? That cannot be good. > Mm, yeah, that wasn't well-thought. Was thinking 0, not r0. Will hav

[PATCH v2, rs6000] Fix PR72827 (ada bootstrap failure)

t expect much change, and the results won't affect our choice to handle this properly in secondary reload. Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions, and the gnattools now build properly so that the ada bootstrap succeeds. Is this ok for trunk? Thanks, B

Re: [PATCH v2, rs6000] Fix PR72827 (ada bootstrap failure)

On Sep 1, 2016, at 9:32 AM, Segher Boessenkool wrote: > > On Wed, Aug 31, 2016 at 09:15:32PM -0500, Bill Schmidt wrote: >> This patch (suggested by Michael Meissner) instead prevents the problem >> by disallowing reg+reg addressing for TImode, allowing D-form addressing >

Re: Do not imply -fweb with -fpeel-loops

If the decision is taken to remove -fweb, please give me a heads-up as I have a target-specific pass that shares infrastructure with it. I can factor that out to facilitate the removal; just let me know. Thanks! -- Bill Bill Schmidt, Ph.D. GCC for LInux on Power Linux on Power Toolchain IBM

[PATCH, rs6000] Fix PR70957 (skip vsx-elemrev-[24].c tests for a downlevel assembler)

execute. Thus this solution. I’ve verified we no longer have test failures on machines with a downlevel assembler, and the tests run correctly on machines with an up-to-date assembler. Is this ok for trunk and 6.2? Thanks, Bill [2016-06-02] Bill Schmidt PR target/70957

[PATCH, rs6000] Fix ICE for vec_ld and vec_st of array when compiled with g++

patch performs that adjustment. I’ve added a test to the C++ torture bucket to verify this now works. Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions. Is this ok for trunk, and eventual backport to the 6 branch? Thanks, Bill [gcc] 2016-06-03 Bill Schmidt

Re: [PATCH, rs6000] Fix ICE for vec_ld and vec_st of array when compiled with g++

You’re right, I don’t need the -O0. I’d like to leave the dg-skip-if in place because I’m worried about older processors not defining altivec, etc. Thanks! Bill > On Jun 3, 2016, at 1:17 PM, Segher Boessenkool > wrote: > > On Fri, Jun 03, 2016 at 11:41:26AM -0500, Bill S

Re: [PATCH,rs6000] Add built-in function support for new Power9 vector absolute difference unsigned instructions

> On Jun 7, 2016, at 2:29 AM, Richard Biener wrote: > > On Tue, Jun 7, 2016 at 1:58 AM, Kelvin Nilsen > wrote: >> >> This patch adds built-in function support for the ISA 3.0 vabsub, >> vabsduh, and vabsduw instructions. >> >> I have bootstrapped and tested on powerpc64le-unkonwn-linux-gnu wi

Re: [PATCH, RFC] First cut at using vec_construct for strided loads

cost (enum vect_cost_for_stmt type_of_cost, > tree vectype, int) > { > - unsigned elements; > - > switch (type_of_cost) > { > case scalar_stmt: > @@ -49546,8 +49561,7 @@ ix86_builtin_vectorization_cost (enum ve >

Re: [PATCH, RFC] First cut at using vec_construct for strided loads

> On Jun 8, 2016, at 9:05 AM, Richard Biener wrote: > > On Wed, 8 Jun 2016, Bill Schmidt wrote: > >> Hi Richard, >> >>> On Jun 8, 2016, at 7:29 AM, Richard Biener >>> wrote: >>> >>> On Wed, Jun 13, 2012 at 4:18 AM, William

[PATCH, rs6000] Fix the vsx-elemrev-[24].c tests in a different way

known-linux-gnu with an out-of-date binutils. Is this ok for trunk? Thanks, Bill 2016-06-10 Bill Schmidt * gcc.target/powerpc/vsx-elemrev-2.c: Change effective target requirements, and disable for AIX for now. * gcc.target/powerpc/vsx-elemrev-4.c: Likewise. Index

Re: [PATCH] Backport PowerPC complex __float128 compiler support to GCC 6.x

Hi Richard, As nobody else has replied, let me take a stab at this one. > On Jun 10, 2016, at 2:06 AM, Richard Biener wrote: > > On Thu, 9 Jun 2016, Michael Meissner wrote: > >> I'm including the global reviewers on the list. I just want to be sure that >> there is no problem installing these

[PATCH, rs6000] Clean up rs6000-builtin.def

2016-06-14 Bill Schmidt * config/rs6000/rs6000-builtin.def (commentary): Typo. (BU_P9_MISC_1): Likewise. (BU_P9_64BIT_MISC_0): Likewise. (BU_P9_MISC_0): Likewise. Index: gcc/config/rs6000/rs6000-builti

[PATCH, rs6000] Prefer vspltisw/h over xxspltib+instruction when available

duces the expected code. I've added a test case to demonstrate the code works properly now in the usual case. Bootstrapped and tested on powerpc64le-unknown-linux-gnu. OK for trunk, and for 6.2 after suitable burn-in? Thanks! Bill [gcc] 2016-06-21 Bill Schmidt * config/rs6

Re: [PATCH, rs6000] Prefer vspltisw/h over xxspltib+instruction when available

> On Jun 21, 2016, at 5:34 PM, Segher Boessenkool > wrote: > > On Tue, Jun 21, 2016 at 03:14:51PM -0500, Bill Schmidt wrote: >> I discovered recently that, with -mcpu=power9, an attempt to generate a >> vspltish instruction resulted instead in an xxspltib followed by

[PATCH, rs6000] Add minimum __float128 built-in support required for glibc

nd for 6.2 after an appropriate burn-in period? Thanks! Bill [gcc] 2016-06-22 Bill Schmidt * config/rs6000/altivec.md (*altivec_vrl): Remove asterisk from name. (altivec_vslo_kf_v8hi): New define_insn. * config/rs6000/rs6000-builtin.def (BU_FLOAT128_2): N

Re: [PATCH, rs6000] Add minimum __float128 built-in support required for glibc

ppy to work with you later on getting the impedance matching right when they become arch-neutral. Thanks! Bill > On Jun 22, 2016, at 3:26 PM, Joseph Myers wrote: > > On Wed, 22 Jun 2016, Bill Schmidt wrote: > >> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with

Re: [PATCH, rs6000] Add minimum __float128 built-in support required for glibc

> On Jun 22, 2016, at 6:27 PM, Joseph Myers wrote: > > On Wed, 22 Jun 2016, Bill Schmidt wrote: > >> Hi Joseph, >> >> That's indeed preferable for the long term -- given how close we are to the >> cutoff for 6.2, though, I'm worried about ad

Re: [PATCH, rs6000] Add minimum __float128 built-in support required for glibc

> On Jun 22, 2016, at 8:10 PM, Bill Schmidt wrote: > >> On Jun 22, 2016, at 6:27 PM, Joseph Myers wrote: >> >> (b) for trunk, having an insn pattern infkf1 for a built-in function that >> loads a constant is not appropriate (other insn patterns to optimize th

[PATCHv2, rs6000] Add minimum __float128 built-in support required for glibc

infinity inside vector registers, or the full-clever one that Segher proposed in response. :) We can try to add that support later if desired. Regstrap in progress for powerpc64le-unknown-linux-gnu. Provided there are no regressions, is this ok? Thanks, Bill [gcc] 2016-06-23 Bill Schmidt

Re: [PATCHv2, rs6000] Add minimum __float128 built-in support required for glibc

e code in 6.2 before it closes. Open to advice. Bill > On Jun 23, 2016, at 4:44 PM, Bill Schmidt wrote: > > Hi, > > This is a revision of my previous patch, correcting two issues. The inff128 > and huge_valf128 builtins now participate in folding so they are suitable > for u

Re: [PATCHv2, rs6000] Add minimum __float128 built-in support required for glibc

the arch-neutral f128 builtins after the 6.2 push completes. If this is acceptable, I'll respin the patch with the new names and we can move ahead. Thanks, Bill > On Jun 23, 2016, at 4:57 PM, Bill Schmidt wrote: > > So, I wasn't quite clear here... this is what I want to be a

Re: [PATCHv2, rs6000] Add minimum __float128 built-in support required for glibc

Thanks, I'll make these changes and re-spin. Not sure what was up with my tabs... > On Jun 23, 2016, at 6:49 PM, Segher Boessenkool > wrote: > > Hi Bill, > > Some little things about the patch... > > On Thu, Jun 23, 2016 at 04:44:27PM -0500, Bill Schmidt wrote

Re: [PATCHv2, rs6000] Add minimum __float128 built-in support required for glibc

> > On Jun 23, 2016, at 5:41 PM, Joseph Myers wrote: > > On Thu, 23 Jun 2016, Bill Schmidt wrote: > >> After discussing with the glibc folks, I'd like to propose that this patch >> be altered to use the 'q' suffix for the builtin names. That w

[PATCHv2q, rs6000] Add minimum __float128 built-in support required for glib

tch and providing an attachment. Please let me know which (if either) is preferable.) Thanks, BIll [gcc] 2016-06-23 Bill Schmidt * config/rs6000/rs6000-builtin.def (BU_FLOAT128_2): New #define. (BU_FLOAT128_1): Likewise. (FABSQ): Likewise. (

Re: [PATCH, rs6000] Add minimum __float128 built-in support required for glibc

> On Jun 27, 2016, at 12:41 PM, Richard Sandiford > wrote: > > Joseph Myers writes: >> On Wed, 22 Jun 2016, Bill Schmidt wrote: >>> The fact that I hook this built-in directly to a pattern named infkf1 >>> doesn't seem to preclude anything you sug

Re: Ping Re: Implement C _FloatN, _FloatNx types [version 3]

Hi Joseph, > On Jun 27, 2016, at 12:21 PM, Joseph Myers wrote: > > Ping. This patch > is pending > review. Built-in functions are available in the followup patch > . I can't

[PATCH, rs6000] Clean up powerpc __float128 tests for older hardware

, Bill 2016-06-28 Bill Schmidt * gcc.target/powerpc/abs128-1.c: Require VSX. * gcc.target/powerpc/copysign128-1.c: Likewise. * gcc.target/powerpc/inf128-1.c: Likewise. * gcc.target/powerpc/nan128-1.c: Likewise. Index: gcc/testsuite/gcc.target/powerpc/abs128-1.c

[PATCH, rs6000] Use direct moves for __builtin_signbit for 128-bit floating-point

y P7-level code generation so that software float128 is used. Bootstrapped and tested on powerpc64[le]-unknown-linux-gnu with no regressions. Is this ok for trunk, and later for 6.2? Thanks, Bill [gcc] 2016-06-28 Michael Meissner Bill Schmidt * config/rs6000/rs600

[PATCH, rs6000] Enable some existing __float128 tests for powerpc64*

es us some additional coverage (10 more tests). Tested on powerpc64[le]-unknown-linux-gnu. Is this ok for trunk, and eventual backport to gcc-6-branch? Thanks, Bill 2016-06-29 Bill Schmidt * gcc.dg/const-float128-ped.c: Enable for powerpc64*-*-*. * gcc.dg/const-float128.c: Lik

Re: [PATCH, rs6000] Fix incorrect mode usage for vec_select

> On Mar 9, 2017, at 2:31 PM, Segher Boessenkool > wrote: > > On Wed, Mar 08, 2017 at 09:47:32AM -0600, Bill Schmidt wrote: >> As noted by Jakub in >> https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00183.html, >> the PowerPC back end incorrectly uses vec_sel

<    1   2   3   4   5   6   7   8   9   10   >