On Wed, Jan 11, 2017 at 04:39:19PM -0600, Segher Boessenkool wrote:
> On Mon, Jan 09, 2017 at 07:32:27PM -0500, Michael Meissner wrote:
> > This patch fixes PR target/79004 by eliminating the optimization of avoiding
> > direct move if we are converting an 8/16-bit integer value
On Wed, Jan 11, 2017 at 04:39:19PM -0600, Segher Boessenkool wrote:
> On Mon, Jan 09, 2017 at 07:32:27PM -0500, Michael Meissner wrote:
> > This patch fixes PR target/79004 by eliminating the optimization of avoiding
> > direct move if we are converting an 8/16-bit integer value
On Tue, Jan 17, 2017 at 07:00:36PM -0600, Segher Boessenkool wrote:
> On Tue, Jan 17, 2017 at 07:39:05PM -0500, Michael Meissner wrote:
> > It turns out the testcase I submitted for pr79004 failed, since I had the
> > wrong
> > syntax for \m and \M (you need to use {
have checked this on a little endian power8 system (64-bit only), a big
endian power8 system (64-bit only), and a big endian power7 system (both 32-bit
and 64-bit), and there were no regressions. Can I check this into the trunk?
[gcc]
2017-01-17 Michael Meissner
* config/rs6000/rs600
On Wed, Jan 18, 2017 at 11:21:40AM -0600, Segher Boessenkool wrote:
> On Tue, Jan 17, 2017 at 08:50:08PM -0500, Michael Meissner wrote:
> > I have checked this on a little endian power8 system (64-bit only), a big
> > endian power8 system (64-bit only), and a big endian power7 syste
ystem. There were no
regressions in the runs. I verified that the float128-hw.c test is now run.
Can I check these changes into the trunk?
[gcc]
2017-01-18 Michael Meissner
* config/rs6000/rs6000-cpus.def (ISA_3_0_MASKS_SERVER): Enable
-mpower9-minmax by default for -mcpu=p
finished with no regressions. Can I check it into trunk?
[gcc]
2017-01-25 Michael Meissner
PR target/79179
* config/rs6000/vsx.md (vsx_extract__store): Use wY
constraint instead of o for the stxsd instruction.
[gcc/testsuite]
2017-01-25 Michael Meissner
PR target
trunk? Since the patch shows up as an abort
in GCC 6 and not in GCC 7 (unless you disable LRA), I would like to apply the
patch as soon as possible to the GCC 6 branch.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone
Well instead of attaching the ChangeLog, I attached the patch without
ChangeLog.
Here is the ChangeLog entry for the patch:
[gcc]
2017-03-24 Michael Meissner
PR target/78543
* config/rs6000/rs6000.md (BSWAP): New mode iterator for modes
with hardware byte swap load
On Fri, Mar 24, 2017 at 07:16:32PM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Fri, Mar 24, 2017 at 07:23:02PM -0400, Michael Meissner wrote:
> > Reload fumbles in certain conditions.
>
> Yeah. And it does not need bswap to get totally lost with this, so this
> pa
does not show by default in
trunk (due to failing with RELOAD), but the bug shows up in GCC 6 (since RELOAD
is default there), and it affects some of the Linux distributions.
[gcc]
2017-03-27 Michael Meissner
PR target/78543
* config/rs6000/rs6000.md (bswaphi2_extenddi): Comb
. Is it ok for the trunk?
[gcc]
2017-04-11 Michael Meissner
PR target/80098
* config/rs6000/rs6000-cpus.def (OTHER_P9_VECTOR_MASKS): Define
masks of options that should be turned off if the VSX vector
options are turned off.
(OTHER_P8_VECTOR_MASKS): Likewise
On Tue, Apr 11, 2017 at 06:04:33PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Apr 11, 2017 at 05:32:41PM -0400, Michael Meissner wrote:
> > PR 80098 is an interaction between -mmodulo (ISA 3.0/power9 GPR modulo
> > instructions) and -mno-vsx where the -mmodulo optio
Michael Meissner
PR target/80099
* config/rs6000/rs6000.c (rs6000_expand_vector_extract): Make sure
that DFmode or DImode as appropriate can go in Altivec registers
before generating the faster sequences for variable vec_extracts.
* config/rs6000/vsx.md
On Fri, Apr 14, 2017 at 03:48:47AM -0500, Segher Boessenkool wrote:
> On Wed, Apr 12, 2017 at 06:45:31PM -0400, Michael Meissner wrote:
> > The problem is rs6000_expand_vector_extract did not check for SFmode being
> > allowed in the Altivec (upper) registers, but the insn i
On Fri, Apr 14, 2017 at 05:07:17PM -0500, Segher Boessenkool wrote:
> On Fri, Apr 14, 2017 at 05:43:28PM -0400, Michael Meissner wrote:
> > On Fri, Apr 14, 2017 at 03:48:47AM -0500, Segher Boessenkool wrote:
> > > On Wed, Apr 12, 2017 at 06:45:31PM -0400, Michael Meissner
ion_lib.ii pre-processed file that I
used to this mail message.
I'll run the other benchmarks and compare it to the baseline version to see
what improvements there are.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet
By the way, if anybody else wanted to try the patches, but did not want to
apply all 33 patches, I cloned the trunk and applied the patches to the
following branch:
svn+ssh://gcc.gnu.org/svn/gcc/branches/ibm/ivopts
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460
opts/powerpc64le-unknown-linux-gnu/./libatomic/.libs::/home/meissner/fsf-build-ppc64le/ivopts/gcc:/home/meissner/fsf-build-ppc64le/ivopts/powerpc64le-unknown-linux-gnu/./libatomic/.libs:
spawn [open ...]
PASS: gcc.dg/sms-4.c execution test
PASS: gcc.dg/sms-4.c scan-rtl-dump-times sms "SMS succ
a 1% regression
* 437.leslie3d had a 1% speedup
* 453.povray had a 1.6% speedup
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
2017-04-19-ivopts-64bit.out.bz2
Description: BZip2 compressed data
sters.
+ Previously, only 64-bit integer types were allowed in the traditional
+ floating point registers.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
ition,
+ on ISA 3.0, 16-bit and 8-bit integer types can be allocated in the vector
+ registers. Previously, only 64-bit integer types were allowed in the
+ traditional floating point registers.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
these changes to gcc 7 for GCC 7.2 as well. These patches depend on
the small integer support, which is not in GCC 6, so they would not be
appropriate for GCC 6.
[gcc]
2017-04-26 Michael Meissner
PR target/79038
PR target/79202
PR target/79203
* config/rs6000/
ink. Cc:ing Mike for that.
TARGET_FPRND is for ISA 2.02 (power5+) which added the various round to integer
instructions. So, unless we are going to stop supporting older machines, it is
needed.
> The rest looks fine. Okay for trunk with those changes, or resend if
> you prefer I take anothe
were run. Can I check this patch
into the trunk?
[gcc]
2017-09-13 Michael Meissner
* config/rs6000/rs6000-builtin.def (BU_FLOAT128_1_HW): New macros
to support float128 built-in functions that require the ISA 3.0
hardware.
(BU_FLOAT128_3_HW): Likewise.
(SQ
On Wed, Sep 13, 2017 at 10:49:43PM +, Joseph Myers wrote:
> On Wed, 13 Sep 2017, Michael Meissner wrote:
>
> > This patch adds support on PowerPC ISA 3.0 for the built-in function
> > __builtin_sqrtf128 generating the XSSQRTQP hardware square root instruction
> &
On Wed, Sep 13, 2017 at 06:08:45PM -0500, Segher Boessenkool wrote:
> On Tue, Sep 12, 2017 at 07:17:07PM -0400, Michael Meissner wrote:
> > On Tue, Sep 12, 2017 at 05:41:34PM -0500, Segher Boessenkool wrote:
> > > This needs "TARGET_HARD_FLOAT && TARGET_DOUBLE_FLOA
On Thu, Sep 14, 2017 at 09:54:14AM -0500, Segher Boessenkool wrote:
> On Wed, Sep 13, 2017 at 05:46:00PM -0400, Michael Meissner wrote:
> > This patch adds support on PowerPC ISA 3.0 for the built-in function
> > __builtin_sqrtf128 generating the XSSQRTQP hardware square root instr
er9 prototype.
Can I check these changes into GCC 8? Can I back port these changes into the
GCC 7 branch?
[gcc]
2017-09-19 Michael Meissner
* config/rs6000/vsx.md (vsx_xscvspdp_scalar2): Move insn so it is
next to vsx_xscvspdp.
(vsx_xscvdpsp_scalar): Use 'ww' const
check this into the trunk? I noticed without this
patch, sometimes the register allocator would do a store and then a load to
move a SImode value from a vector register to a GPR and sign extend it, instead
of doing the move and then the sign extension.
2017-09-25 Michael Meissner
* config
check this into the trunk? Compared to the previous
patch, I simplified this to use zero_extendsidi2 instead of using an UNSPEC,
and I deleted the UNSPEC.
2017-09-25 Michael Meissner
* config/rs6000/rs6000.md (movsi_from_sf): Adjust code to
eliminate doing a 32-bit shift right or
assumes the value has already been rounded, and does not
raise an exception in case of a Nan).
2017-09-25 Michael Meissner
* config/rs6000/rs6000.md (movsi_from_df): Optimize converting a
DFmode to a SFmode, and then needing to move the SFmode to a GPR
to use the XSCVDPSP
check this into the trunk? This is a cosmetic change,
in that I noticed the two insns providing XSCVDPSP were separated by another
insn, and it moves the 2nd insn to be adjacent to the first.
2017-09-25 Michael Meissner
* config/rs6000/vsx.md (vsx_xscvspdp_scalar2): Move insn so that
patch uses the proper constraint ("ww") so we can avoid a move
instruction.
2017-09-25 Michael Meissner
* config/rs6000/vsx.md (vsx_xscvdpsp_scalar): Use "ww" constraint
instead of "f" to allow SFmode to be in traditional Altivec
registers.
'?'. The
theory was we might want to favor Altivec or FPR registers for a given vector
type. However, we've never done this. Further more with the change to use
LRA instead of reload, this isn't as useful. So, as I encounter these dual
alternatived, I have be
9-25 Michael Meissner
* config/rs6000/vsx.md (peephole for optimizing move SF to GPR):
Adjust code to eliminate needing to do the shift right 32-bits
operation after XSCVDPSPN.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
e
check this into the trunk? It fixes the two tests
(pr71977-1.c and direct-move-float1.c) that need to be adjusted with the
previous patches applies. It also adds a new test to test combining round from
DFmode to SFmode and move it to a GPR.
2017-09-25 Michael Meissner
* gcc.target/powerpc
veclogical")
> > +vecexts,mffgpr")
>
> vecsimple or vecfloat I guess, not vecexts. We have no way of describing
> it exactly, of course. Maybe just "two".
Ok.
> Okay for trunk with those things taken care of. Thanks!
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
On Tue, Sep 26, 2017 at 11:36:14AM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Sep 26, 2017 at 10:34:44AM -0400, Michael Meissner wrote:
> > * config/rs6000/rs6000.md (movsi_from_df): Optimize converting a
> > DFmode to a SFmode, and then needing to mov
On Tue, Sep 26, 2017 at 04:56:54PM -0500, Segher Boessenkool wrote:
> On Tue, Sep 26, 2017 at 10:48:29AM -0400, Michael Meissner wrote:
> > * config/rs6000/vsx.md (peephole for optimizing move SF to GPR):
> > Adjust code to eliminate needing to do the shift right 32-bits
&g
back out this particular patch. I have done a full
bootstrap and regression test, there were no regressions, and the new test case
does run correctly. Can I check this into the trunk?
[gcc]
2017-09-27 Michael Meissner
* config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Define
that the new
test (float128-odd.c) did run sucessfully. Can I check this patch into the
trunk?
[gcc]
2017-09-28 Michael Meissner
* config/rs6000/rs6000-builtin.def (BU_FLOAT128_2_HW): Define new
helper macro for IEEE float128 hardware built-in functions.
(SQRTF128_ODD
On Thu, Sep 28, 2017 at 12:40:24AM +, Joseph Myers wrote:
> On Wed, 27 Sep 2017, Michael Meissner wrote:
>
> > The glibc team has requested we define the standard macro
> > (__FP_FAST_FMAF128)
> > for PowerPC code when we have the IEEE 128-bit floating point hardware
On Fri, Sep 29, 2017 at 12:10:07PM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Thu, Sep 28, 2017 at 06:34:23PM -0400, Michael Meissner wrote:
> > This patch addss built-in functions on PowerPC ISA 3.0 (power9) that allow
> > the
> > user to access the round t
On Thu, Sep 28, 2017 at 12:40:24AM +, Joseph Myers wrote:
> On Wed, 27 Sep 2017, Michael Meissner wrote:
>
> > The glibc team has requested we define the standard macro
> > (__FP_FAST_FMAF128)
> > for PowerPC code when we have the IEEE 128-bit floating point hardware
Whoops, I forgot to attach the patch.
On Mon, Oct 02, 2017 at 07:51:00PM -0400, Michael Meissner wrote:
> On Thu, Sep 28, 2017 at 12:40:24AM +, Joseph Myers wrote:
> > On Wed, 27 Sep 2017, Michael Meissner wrote:
> >
> > > The glibc team has requested we d
.
[gcc/testsuite]
2017-10-03 Michael Meissner
* gcc.target/powerpc/float128-odd.c: New test.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000-builtin.def
into the trunk
assuming the power9 bootstrap/make check passes without regressions?
[gcc]
2017-10-05 Michael Meissner
* config/rs6000/amo.h: New include file to provide ISA 3.0 atomic
memory operation instruction support.
* config.gcc (powerpc*-*-*): Include amo.h as an
On Fri, Oct 06, 2017 at 11:45:10AM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Thu, Oct 05, 2017 at 06:14:14PM -0400, Michael Meissner wrote:
> > This patch adds support for most of the PowerPC ISA 3.0 Atomic Memory
> > Operation
> > instructions, listed i
On Fri, Oct 06, 2017 at 01:25:33PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Oct 06, 2017 at 02:03:43PM -0400, Michael Meissner wrote:
> > > Do you really need the mr insns? Can't you express that in the
> > > arguments? Perhaps using a union of __int
On Mon, Oct 09, 2017 at 11:03:10AM -0500, Segher Boessenkool wrote:
> On Fri, Oct 06, 2017 at 02:30:16PM -0400, Michael Meissner wrote:
> > Here is the revised amo.h. I tested the two test files amo1.c and amo2.c,
> > and
> > they both compile. It is interesting, use %P0 re
Mike, does this look correct? Was there a
> reason it used fpr_reg_operand?
>
> Bootstrapped and tested on powerpc64-linux.
I dunno, we need to look at why somebody is putting a GPR in there in the first
place. The instruction doesn't support GPRs. Perhaps the generator funct
cause it was covered by existing tests. Can I check
this into trunk?
2017-01-30 Michael Meissner
PR target/78597
PR target/79038
* config/rs6000/rs6000-protos.h (convert_float128_to_int): Delete,
no longer used.
(convert_int_to_float128): Lik
s a
32-bit shift right in the GPR). Similarly, going from a GPR to a vector
register, we do a shift left 32-bits, direct move, and then convert from vector
format to scalar format.
So to enable the code that was causing the problem, you need 64-bit. In
32-bit, it does a store, ori 2,2,0, and then a
On Fri, Feb 03, 2017 at 09:11:38PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 03, 2017 at 03:05:58PM -0500, Michael Meissner wrote:
> > > > --- gcc/testsuite/gcc.target/powerpc/pr79354.c.jj 2017-02-03
> > > > 02:37:44.147938375 +0100
> > > > +++ gcc
acation on Wednesday (February 8th), and I will
return to work on Friday February 24th. If I don't get the approval by Monday,
I will likely hold the patches until I return to work.
[gcc]
2017-02-03 Michael Meissner
PR target/66144
* config/rs6000/vector.md (v
On Fri, Feb 03, 2017 at 06:07:56PM -0600, Segher Boessenkool wrote:
> On Fri, Feb 03, 2017 at 04:25:00PM -0500, Michael Meissner wrote:
> > +;; Return 1 if operand is either a vector constant of all 0 bits of a
> > vector
> > +;; constant of all 1 bits.
> > +(define_pre
On Fri, Feb 03, 2017 at 06:07:56PM -0600, Segher Boessenkool wrote:
> On Fri, Feb 03, 2017 at 04:25:00PM -0500, Michael Meissner wrote:
> > +;; Return 1 if operand is either a vector constant of all 0 bits of a
> > vector
> > +;; constant of all 1 bits.
> > +(define_pre
correctly switches __{add,sub,mul,div}kf3 to use
the hardware instructions.
Yeah, if there is a demand for -mfloat128-hardware -m32, we could do it, but
for now I think it is best to require 64-bit.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
t ran successfully in 64-bit
mode. Can I check this patch into the trunk?
Since the bug was reported against GCC 6, can I apply the patch to GCC 6
assuming the patch applies cleanly and has no regressions after a burn in
period on the GCC 7 trunk?
[gcc]
2017-02-28 Michael Meissner
PR t
On Wed, Mar 01, 2017 at 05:21:44AM -0600, Segher Boessenkool wrote:
> On Wed, Mar 01, 2017 at 01:37:14AM -0500, Michael Meissner wrote:
> > This patch fixes PR target/79439, which is a recursive call when the 64-bit
> > code is compiled with -fpic doesn't have the NOP af
this
patch via bootstrap and make check and there were no regressions. Can I check
this patch into the trunk?
[gcc]
2017-03-03 Michael Meissner
PR target/79038
* config/rs6000/rs6000.md (float2): Define
insns to convert from signed/unsigned char/short to IEEE 128-bit
28
(match_operand:VSX_LE_128 1 "input_operand" ",Z,")
(const_int 64)))]
"!BYTES_BIG_ENDIAN && TARGET_VSX && !TARGET_P9_VECTOR"
"@
xxpermdi %x0,%x1,%x1,2
lxvd2x %x0,%y1
stxvd2x %x1,%y0"
[(set_attr "length" "4&qu
On Fri, Mar 03, 2017 at 02:58:06PM -0600, Segher Boessenkool wrote:
> On Fri, Mar 03, 2017 at 03:43:03PM -0500, Michael Meissner wrote:
> > On Fri, Mar 03, 2017 at 02:19:57PM -0600, Segher Boessenkool wrote:
> > > On Fri, Mar 03, 2017 at 05:28:27PM +0100, Jakub Jelinek wrote:
&g
On Thu, Mar 09, 2017 at 12:45:00PM -0600, Segher Boessenkool wrote:
> On Fri, Mar 03, 2017 at 01:10:18PM -0500, Michael Meissner wrote:
> > On January 31st I commited a patch that improves conversion of
> > signed/unsigned
> > char/short values to 32-bit and 64-bit flo
ecall. Perhaps it is related to:
2016-12-19 Will Schmidt
* config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Add handling for
early expansion of vector multiply and subtract builtins.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
does
not cause any regressions. Is it ok to apply to the trunk? Assuming there are
no additional problems, can I apply the patch to the GCC 5 and 6 branches as
well?
[gcc]
2017-03-14 Michael Meissner
PR target/79947
* config/rs6000/rs6000.h (TARGET_FRSQRTES): Add check for
hey would likely see the issue. GCC 7 has switched to LRA, which is more
robust, and doesn't show the problem (unless you use the -mno-lra switch).
[gcc]
2017-03-15 Michael Meissner
PR target/71294
* config/rs6000/vsx.md (vsx_splat_, VSX_D iterator): Allow a
SPLAT o
apply to the trunk? I would like to apply it to the gcc 5
branch as well. Is this ok also?
[gcc]
2016-03-11 Michael Meissner
PR target/70131
* config/rs6000/rs6000.md (round322_fprs): Do not do the
optimization if we have direct move.
(roundu322_fprs): Likewise.
CLWdO.o: In function `print_hex.constprop.0':
test-float128-6.c:(.text+0x84): undefined reference to `__extendkftf2'
collect2: error: ld returned 1 exit status
If built a compiler with the patch, it succeeds. Is this patch ok to install
in the trunk?
2016-03-22 Michael M
sions. Sorry about enabling it by default.
2016-03-23 Michael Meissner
PR target/70381
* config/rs6000/rs6000-cpus.def (ISA_2_6_MASKS_SERVER): Do not set
-mfloat128 here.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email:
he IEEE 128-bit
floating point emulator in libgcc is indeed built. Are these patches ok to
install in the GCC trunk?
[gcc]
2016-04-07 Michael Meissner
PR target/70589
* config/rs6000/rs6000.c (rs6000_opt_masks): Disable using the
target attribute and pragma from changing
int.
(ieee_128bit_vsx_abs2_internal): Likewise.
(ieee_128bit_vsx_nabs2_internal): Likewise.
(ieee_128bit_vsx_nabs2): Correct splitter so that it
generates (neg (abs ...)) instead of (abs ...).
[gcc/testsuite]
2016-04-12 Michael Meissner
PR target/70680
test and obvious, I went ahead and commited the following
patch:
2016-04-14 Michael Meissner
PR target/70640
* gcc.target/powerpc/pr70640.c: Fix test so it correctly works on
a power7 system that does not have an assembler that supports
power8.
--
Michael Mei
. Is it ok to apply to the GCC trunk?
[gcc]
2016-04-14 Michael Meissner
PR target/70669
* config/rs6000/rs6000.c (rs6000_init_hard_regno_mode_ok): Add
direct move handlers for KFmode. Change TFmode handlers test from
FLOAT128_IEEE_P to FLOAT128_VECTOR_P.
[gcc
re no regressions. Is this patch ok to check into the trunk?
2016-09-19 Michael Meissner
* config/rs6000/rs6000.c (rs6000_expand_vector_init): For V4SF
inits on power8 and above, use the VMRGEW instruction instead of a
permute.
* config/rs6000/altiv
years with the
PowerPC is that it can be rather expensive to move things from the floating
point/vector unit to the integer registers and vice versa. This is
particularly true if you having to do the transfer via the memory unit via
stores and loads of different sizes.
--
Michael Meissner, IBM
I
On Mon, Sep 19, 2016 at 05:43:19PM -0500, Segher Boessenkool wrote:
> On Mon, Sep 19, 2016 at 06:02:08PM -0400, Michael Meissner wrote:
> > vector float combine (float a, float b, float c, float d)
> > {
> > return (vector float) { a, b, c, d };
> > }
>
> [ .
On Mon, Sep 19, 2016 at 06:20:59PM -0500, Segher Boessenkool wrote:
> On Mon, Sep 19, 2016 at 06:51:42PM -0400, Michael Meissner wrote:
> > > > However ISA 2.07 (i.e. power8) added the VMRGEW instruction, which can
> > > > do this
> > > > more simply:
>
On Tue, Sep 20, 2016 at 01:19:07PM +0100, Tamar Christina wrote:
> On 19/09/16 23:16, Michael Meissner wrote:
> >On Mon, Sep 12, 2016 at 04:19:32PM +, Tamar Christina wrote:
> >>Hi All,
> >>
> >>This patch adds an optimized route to the fpclassify builtin
not do the full bootstrap and make
check sequence. I can do this if you prefer.
Is the patch ok to put into the trunk?
2016-09-20 Michael Meissner
PR target/77670
* config/rs6000/predicates.md (invert_fpmask_comparison_operator):
New predicate that matches the ISA 3.
check with no regressions on a little endian Power8 system. Can I apply this
patch to the gcc 6.x branch?
2016-09-29 Michael Meissner
Back port from trunk
2016-09-21 Michael Meissner
PR target/77670
* config/rs6000/predicates.md
ch in the trunk?
[gcc]
2016-10-03 Michael Meissner
* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Split
-mfloat128 into -mfloat128-type that enables the IEEE 128-bit
floating point type infrastructre, and -mfloat128 that enables the
keyword. Define
On Tue, Oct 04, 2016 at 09:42:21PM +, Joseph Myers wrote:
> On Tue, 4 Oct 2016, Michael Meissner wrote:
>
> > It also changes __ibm128/__float128, and only registers the keywords if the
> > long double type is not IBM extended double or IEEE 128-bit floating point
> &g
On Tue, Oct 04, 2016 at 09:42:21PM +, Joseph Myers wrote:
> On Tue, 4 Oct 2016, Michael Meissner wrote:
>
> > It also changes __ibm128/__float128, and only registers the keywords if the
> > long double type is not IBM extended double or IEEE 128-bit floating point
> &g
On Thu, Oct 06, 2016 at 05:19:39PM -0500, Segher Boessenkool wrote:
> On Wed, Oct 05, 2016 at 06:18:50PM -0400, Michael Meissner wrote:
> > I have removed the #define of __float128, and instead created a keyword that
> > points to the _Float128 type. I added a little commentar
to apply the
patch?
2016-10-10 Michael Meissner
PR target/77924
* config/rs6000/rs6000.c (rs6000_init_builtins): Only create the
distinct __ibm128 IBM extended double type if long doubles are
128-bits and the default format for long double is IEEE 128-bit.
Index
other benchmarks were
performance neutral. The difference is it eliminates some load/store of GPRs
and move directs in favor of doing the load/store 32-bit integer instructions
to the FPRs.
[gcc]
2016-10-26 Michael Meissner
* config/rs6000/constraints.md (wH constraint): Add new
small
integers can go in vector registers.
After this, I plan to work on setting vector elements, which will be easier if
the small integer types can go in vector registers.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com
On Thu, Oct 27, 2016 at 02:55:51PM -0500, Segher Boessenkool wrote:
> On Wed, Oct 26, 2016 at 06:51:54PM -0400, Michael Meissner wrote:
> > (zero_extendsi2): Reorder pattern, so RLDICL comes before
> > the FPR and VSX loads, but before MTVSRWZ. Remove ??, ! from the
>
o the improvements in the SImode extraction and when
464.h264ref is auto vectorized, one of the extracts converted to floating point
and generated the new code. However, neither change affected the performance
of those two benchmarks.
Can I check this into the trunk?
[gcc]
2016-10-31 Michael Mei
On Mon, Oct 31, 2016 at 06:04:47PM -0500, Segher Boessenkool wrote:
> On Mon, Oct 31, 2016 at 05:25:56PM -0400, Michael Meissner wrote:
> > +(define_insn "vsx_xvcvsxwdp_df"
> > + [(set (match_operand:DF 0 "vsx_register_operand" "=ws&quo
does not support #pragma GCC target nor the target attribute.
One question is how many of the billions and billions (ok, 1,345) of the rs6000
built-ins would be improved by expanding them in gimple time rather than rtl?
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
, and
the fix for PR 71677 that was submitted on June 27th being installed before
these patches can be applied.
Assuming the above patches are supplied can I back port it to the GCC 6.2 after
a burn-in period?
[gcc]
2016-06-29 Michael Meissner
* config/rs6000/predicates.md
On Wed, Jun 29, 2016 at 03:33:24PM -0400, Michael Meissner wrote:
> This patch adds support to generate the ISA 3.0 VEXTRACTUB, VEXTRACTUH, and
> XXEXTRACTUW instructions to extract a constant element from the small vector
> integer types. I also added support to generate STXSIWX if a
a burn-in period?
2016-06-29 Michael Meissner
PR target/71677
* config/rs6000/constraints.md (wY constraint): New constraint to
match the requirements for the LXSD and STXSD instructions.
* config/rs6000/predicates.md (offsettable_mem_14bit_operand): New
On Wed, Jun 29, 2016 at 05:20:26PM -0500, Segher Boessenkool wrote:
> On Wed, Jun 29, 2016 at 03:33:24PM -0400, Michael Meissner wrote:
> > Is it ok to install in the trunk?
>
> See comments below. Okay with that taken care of.
>
> > Ideally, I would like to also i
On Wed, Jun 29, 2016 at 06:06:04PM -0500, Segher Boessenkool wrote:
> On Wed, Jun 29, 2016 at 05:58:37PM -0400, Michael Meissner wrote:
> > Assuming there are no regressions in power7, are these patches ok to
> > install in
> > the trunk, and backport to GCC 6.2 after a bur
And yes, the reply was to the other patch in play (vector extract).
I think it is time to go home for the night, and I will commit the fix for PR
71677 tomorrow. :-)
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone
-06-30 Michael Meissner
PR target/71720
* config/rs6000/vsx.md (vsx_splat_v4sf_internal): When splitting
the insns, use vsx_xxspltw_v4sf_direct which does not check for
little endian.
[gcc/testsuite]
2016-06-30 Michael Meissner
PR target/71720
901 - 1000 of 2088 matches
Mail list logo
