It would help if I included the patch.
On Mon, Jun 13, 2016 at 01:28:16PM -0400, Michael Meissner wrote:
> This patch goes through the PowerPC compiler and adds support to allow DImode
> (64-bit integers) into Altivec registers for VSX systems. It also adds some
> support to allow loa
double format) and KFmode (IEEE
128-bit format). IFmode widens to KFmode which widens to TFmode. A backend
hook is used to not allow IBM long double to widen to IEEE long double and vice
versa. At the moment, since there is no wider type than 128-bits, it isn't an
issue.
Note, I do feel the front ends should be modified to allow __complex __float128
directly rather than having to use an attribute to force the complex type (and
to use mode(TF) on x86 or mode(KF) on PowerPC). It would clean up both x86 and
PowerPC. However, those patches aren't written yet.
> [I realize this is just backports but at least the layout_type change
> looks dangerous to me]
>
> Thanks,
> Richard.
>
--
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, Jun 14, 2016 at 05:53:46PM -0500, Segher Boessenkool wrote:
> On Mon, Jun 13, 2016 at 02:29:41PM -0400, Michael Meissner wrote:
> > It would help if I included the patch.
>
> :-)
>
> > > Are these changes ok to install in the trunk? Assuming they go in th
On Wed, Jun 15, 2016 at 02:51:20PM -0500, Segher Boessenkool wrote:
> On Wed, Jun 15, 2016 at 02:24:41PM -0400, Michael Meissner wrote:
> > > > ; Some DImode loads are best done as a load of -1 followed by a mask
> > > > ; instruction.
> > > > (define_spl
On Wed, Jun 15, 2016 at 03:12:55PM +0200, Richard Biener wrote:
> On Wed, 15 Jun 2016, Michael Meissner wrote:
> > Eventually, I decided to punt having to have explicit paths for widening. I
> > used fractional modes for IFmode (ibm long double format) and KFmode (IEEE
>
companion patch for
6.2 once this goes into the trunk.
I bootstrapped the compiler and did a make check with no regressions on a big
endian Power 7 system and a little endian Power 8 system. Is it ok to go into
the trunk?
[gcc]
2016-06-21 Michael Meissner
* stor-layout.c (layout_type): Move
On Thu, Jun 16, 2016 at 10:06:48PM +, Joseph Myers wrote:
> On Wed, 15 Jun 2016, Michael Meissner wrote:
>
> > Note, I do feel the front ends should be modified to allow __complex
> > __float128
> > directly rather than having to use an attribute to force the compl
,
etc.
As I said in my previous message, what ever we do in this space needs to be
backwards compatible with existing usage in GCC 6.x.
--
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
endian power7 and a little endian power8 systems with
no regressions. Is it ok to apply to the GCC 6.2 branch?
[gcc]
2016-06-22 Michael Meissner
Back port from trunk
2016-06-21 Michael Meissner
* stor-layout.c (layout_type): Move setting complex MODE to
layout_t
llocation, since the instruction only uses indexed
addressing.
I bootstrapped the compiler and ran make check with no regressions on a little
endian power8 system. Can I check it into trunk, and after an appropriate
waiting period check it into GCC 6.x if there were no issues?
[gcc]
2016-06-
these patches ok to check
into the trunk, and after a burn-in period, check them into the GCC 6.2 branch?
[gcc]
2016-06-23 Michael Meissner
* config/rs6000/vsx.md (UNSPEC_P9_MEMORY): New unspec to support
loading and storing byte/half-word values in the vector registers
On Mon, Jun 27, 2016 at 03:05:19PM -0500, Segher Boessenkool wrote:
> On Thu, Jun 23, 2016 at 06:37:15PM -0400, Michael Meissner wrote:
> > PowerPC ISA 3.0 adds new instructions (LXSIHZX, LXSIBZX, STXSIHX, and
> > STXSIBX)
> > that allow you to load and zero extend byte and
On Mon, Jun 27, 2016 at 09:37:16PM -0500, Segher Boessenkool wrote:
> On Mon, Jun 27, 2016 at 08:08:20PM -0400, Michael Meissner wrote:
> > This patch fixes PR 71667 that I discovered when trying to build the Spec
> > 2006
> > xalancbmk benchmark for the Power9. The Altive
On Tue, Jun 28, 2016 at 12:49:12PM -0500, Segher Boessenkool wrote:
> On Tue, Jun 28, 2016 at 01:27:45PM -0400, Michael Meissner wrote:
>
>
>
> Thanks for the explanation.
>
> > I think the thing to do is create yet another memory constraint, that is
> > just
&
xalancbmk benchmark now builds. I will kick off a big endian
build on a power7 system.
Assuming there are no regressions in power7, are these patches ok to install in
the trunk, and backport to GCC 6.2 after a burn-in period?
2016-06-28 Michael Meissner
PR target/71667
* config
; Thanks,
> Alan.
Whoops, yes you are correct. Thanks for pointing that out.
--
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 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 Thu, Oct 19, 2017 at 10:15:44PM +, Joseph Myers wrote:
> On Thu, 19 Oct 2017, Michael Meissner wrote:
>
> > 1) I switched to use DEF_EXT_LIB_BUILTIN to declare the _Float
> > and
> > _FloatX functions. This allows treating __builtin_sqrtf128 the
]
2017-10-20 Michael Meissner
* config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Define
__FLOAT128_HARDWARE__ to be 2 if float128 built-in functions are
available.
* extend.texi (PowerPC Built-in Functions): Document setting
__FLOAT128_HARDWARE__ to
these patches on a little endian power8 system, and
there were no regressions. Can I check these patches into the trunk?
2017-10-21 Michael Meissner
* config/rs6000/aix.h (TARGET_IEEEQUAD_DEFAULT): Set long double
default to IBM.
* config/rs6000/dar
On Thu, Oct 19, 2017 at 10:15:44PM +, Joseph Myers wrote:
> On Thu, 19 Oct 2017, Michael Meissner wrote:
>
> > 1) I switched to use DEF_EXT_LIB_BUILTIN to declare the _Float
> > and
> > _FloatX functions. This allows treating __builtin_sqrtf128 the
On Tue, Oct 24, 2017 at 11:08:15PM +, Joseph Myers wrote:
> On Tue, 24 Oct 2017, Michael Meissner wrote:
>
> > This patch adds a new switch (-fimplicit-math-floatn) that when enabled, it
> > will add implicit declarations for copysign, fabs, fma, fmax, fmin, nan, and
&
On Tue, Oct 24, 2017 at 11:08:15PM +, Joseph Myers wrote:
> On Tue, 24 Oct 2017, Michael Meissner wrote:
>
> > This patch adds a new switch (-fimplicit-math-floatn) that when enabled, it
> > will add implicit declarations for copysign, fabs, fma, fmax, fmin, nan, and
&
Whoops, I missed deleting c.opt from the ChangeLog file. I did update the
builtins.def text, and c-cppbuiltins.c, but I didn't delete c.opt.
--
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 Wed, Oct 25, 2017 at 08:10:45PM +, Joseph Myers wrote:
> On Wed, 25 Oct 2017, Michael Meissner wrote:
>
> > +static const char *const fltfn_suffixes[] = { "F16", "F32", "F128", "F32X",
> > +
On Wed, Oct 25, 2017 at 08:31:33PM +, Joseph Myers wrote:
> On Wed, 25 Oct 2017, Michael Meissner wrote:
>
> > > I don't think that, given the availability of fmaf128 etc. built-in
> > > functions with appropriate options, whether __FP_FAST_* are defined
> &
ius patch. With this
change, can I check it into the trunk (once Segher approves of the minor bit to
take out the PowerPC __builtin_{sqrtf128,fmaf128} builtins.
2017-10-25 Michael Meissner
* doc/cpp.texi (Common Predefined Macros): Document defining
__FP_FAST_FMAF and __FP_FAST
On Wed, Oct 25, 2017 at 06:56:20PM -0500, Segher Boessenkool wrote:
> On Fri, Oct 20, 2017 at 04:56:41PM -0400, Michael Meissner wrote:
> > This is a simple patch to add a way that the GLIBC team call tell that
> > certain
> > __float128 built-in functions are available. W
On Wed, Oct 25, 2017 at 07:57:09PM -0400, Michael Meissner wrote:
> On Wed, Oct 25, 2017 at 11:41:24PM +, Joseph Myers wrote:
> > My only comment on this version is that the documentation in cpp.texi of
> > __FP_FAST_* should be updated to mention __FP_FAST_FMAF@var{n} and
>
On Wed, Oct 25, 2017 at 07:11:07PM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Sat, Oct 21, 2017 at 09:09:58AM -0400, Michael Meissner wrote:
> > As Segher and I were discussing off-line, I have some problems with the
> > current
> > -mabi={ieee,ibm}longdou
,
roundf128, truncf128, and roundf128 to the PowerPC backend when you use
-mcpu=power9.
I have done bootstrap builds on both x86-64 and a little endian power8 system.
Can I install these patches to the trunk?
[gcc]
2017-10-27 Michael Meissner
* builtins.def: (_Float and _FloatX BUILT_IN_CEIL
t-in function available under a public name, in
> the case where __float128 exists for C++, is a matter for libstdc++
> headers.
Arghh, yes, I can restrict it to just the C language. Would you prefer just
that? Do we want a target hook to be able to over-ride this on a platform
basis (wit
On Mon, Oct 30, 2017 at 06:32:44PM +, Joseph Myers wrote:
> On Mon, 30 Oct 2017, Michael Meissner wrote:
>
> > > One obvious possible fix would be for the builtins.def macros never to
> > > define public names such as sqrtf128 for C++, only ever for C. That
>
The x86-64 bootstrap/make check run has now finished, and there were no
regressions. Can I check the changes into trunk?
--
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 Mon, Oct 30, 2017 at 11:30:12PM +, Joseph Myers wrote:
> On Mon, 30 Oct 2017, Michael Meissner wrote:
>
> > This patch fixes exporting the non __builtin_ names to be done by default
> > only
> > for the C language. I added a target hook in case a port needs to en
On Mon, Oct 30, 2017 at 11:30:12PM +, Joseph Myers wrote:
> On Mon, 30 Oct 2017, Michael Meissner wrote:
>
> > This patch fixes exporting the non __builtin_ names to be done by default
> > only
> > for the C language. I added a target hook in case a port needs to en
On Wed, Nov 01, 2017 at 01:31:57PM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Fri, Oct 27, 2017 at 06:39:21PM -0400, Michael Meissner wrote:
> > The power9 (running PowerPC ISA 3.0) has a round to integer instruction
> > (XSRQPI) that does various flavors of round an
GCC
7.x).
[gcc]
2017-11-03 Michael Meissner
PR target/82748
* config/rs6000/rs6000-builtin.def (BU_FLOAT128_1): Delete
float128 helper macros, which are no longer used after deleting
the old 'q' built-in functions, and moving the round to odd
bu
On Mon, Nov 06, 2017 at 05:56:59AM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Nov 03, 2017 at 06:07:38PM -0400, Michael Meissner wrote:
> > This patch fixes PR 82748, which is a compiler abort if you use the old
> > __builtin_fabsq function when you are changing th
;t an
issue on the gcc 6.x branch)?
[gcc]
2017-07-07 Michael Meissner
PR target/81348
* config/rs6000/rs6000.md (HI sign_extend splitter): Use the
correct operand in doing the split.
[gcc/testsuite]
2017-07-07 Michael Meissner
PR target/81348
* gcc.t
On Fri, Jul 07, 2017 at 07:22:04AM -0500, Segher Boessenkool wrote:
> On Wed, Jun 28, 2017 at 02:28:23PM -0400, Michael Meissner wrote:
> > Some minor changes to the PowerPC target_clones support:
> >
> > 1) I added a warning if target_clones was used and the compiler
dware capability bits.
Can I install these patches on the trunk? After a burn-in period, can I
install equivalent patches to GCC 7 (which added the __builtin_cpu* built-in
functions)?
[gcc]
2017-07-12 Michael Meissner
PR target/81193
* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins
On Wed, Jul 12, 2017 at 04:07:42PM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Wed, Jul 12, 2017 at 11:38:11AM -0400, Michael Meissner wrote:
> > I also changed the current warning in target_clones handling to be an error
> > instead of a warning, since it really
Hmmm, I didn't realize that gcc 6.x also supported __builtin_cpu_*. I imagine
we will need backports there as well.
--
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 Thu, Jul 13, 2017 at 03:57:08PM -0500, Segher Boessenkool wrote:
> On Wed, Jul 12, 2017 at 07:19:27PM -0400, Michael Meissner wrote:
> > Hmmm, I didn't realize that gcc 6.x also supported __builtin_cpu_*. I
> > imagine
> > we will need backports there as well.
>
CC 6 and 7?
2017-07-18 Michael Meissner
PR target/81193
* gcc.target/powerpc/cpu-builtin-1.c: Change test to use #ifdef
__BUILTIN_CPU_SUPPORTS to see if the GLIBC is new enough that
__builtin_cpu_is and __builtin_cpu_supports are supported.
--
Michael Meissner,
On Wed, Jul 19, 2017 at 12:33:03PM -0500, Segher Boessenkool wrote:
> On Tue, Jul 18, 2017 at 04:24:47PM -0400, Michael Meissner wrote:
> > This patch modifies the change I made on July 12th. It modifies the test
> > for
> > the __builtin_cpu_is and __builtin_cpu_supports
it will work someday.
In writing the tests, I discovered two of the float128 tests could have the
target requiements/options tweaked, and I included those changes here. I also
discovered we had parallel bits for setting up power7, and I used the ISA 2.06
mask in the power7 definition.
S
dform* options.
Is this ok for trunk? At present, I do not intend to back port this to GCC 7
(but if the maintainers want that, I can do it).
[gcc]
2017-07-22 Michael Meissner
* config/rs6000/rs6000-cpus.def (ISA_2_6_MASKS_SERVER): Delete
upper-regs op
On Mon, Jul 24, 2017 at 05:21:15AM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Sat, Jul 22, 2017 at 02:46:04AM -0400, Michael Meissner wrote:
> > One thing that I did was continue to define __UPPER_REGS_{DF,SF,DI}__ that
> > were
> > previously defined. I can
3.0 d-form options.
2017-07-24 Michael Meissner
* config/rs6000/rs6000.c (rs6000_init_hard_regno_mode_ok):
Eliminate TARGET_UPPER_REGS_{DF,DI} usage.
* config/rs6000/rs6000.h (TARGET_UPPER_REGS_DF): Poison macro.
(TARGET_UPPER_REGS_SF): Likewise.
* config/r
On Tue, Jul 25, 2017 at 07:34:46AM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Mon, Jul 24, 2017 at 07:40:26PM -0400, Michael Meissner wrote:
> > This patch eliminates the TARGET_UPPER_REGS_{DF,SF} macros. The next patch
> > will eliminate TARGET_UPPER_REGS_DI.
>
on the trunk.
2017-07-25 Michael Meissner
* config/rs6000/rs6000.c (rs6000_option_override_internal):
Eliminate TARGET_UPPER_REGS_DI.
(rs6000_expand_vector_set): Likewise.
* config/rs6000/vsx.md (vsx_set__p9): Likewise.
(vsx_set_v4sf_p9): Likewise
heck these changes into the trunk?
My next cleanup patch may be elimination of the three options for power9/ISA
3.0 d-form (register+offset) support. Another one will probably be deleting of
the direct move option (power8/ISA 2.07).
[gcc]
2017-07-25 Michael Meissner
* config/rs6000/rs600
I forgot to include the patch for these changes:
[gcc]
2017-07-25 Michael Meissner
* config/rs6000/rs6000-cpus.def (ISA_2_7_MASKS_SERVER): Delete
-mvsx-small-integer option.
(ISA_3_0_MASKS_IEEE): Likewise.
(POWERPC_MASKS): Likewise.
* config/rs6000
And not only the patches to the compiler, I forgot to include the testsuite
patches:
[gcc/testsuite]
2017-07-25 Michael Meissner
* gcc.target/powerpc/vsx-himode.c: Delete -mvsx-small-integer
option.
* gcc.target/powerpc/vsx-himode2.c: Likewise.
* gcc.target
On Wed, Jul 26, 2017 at 03:02:15PM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Wed, Jul 26, 2017 at 12:24:17AM -0400, Michael Meissner wrote:
> > * config/rs6000/rs6000-cpus.def (ISA_2_7_MASKS_SERVER): Delete
> > -mvsx-small-integer option.
> > (IS
This is the final patch that I committed.
[gcc]
2017-07-26 Michael Meissner
* config/rs6000/rs6000-cpus.def (ISA_2_7_MASKS_SERVER): Delete
-mvsx-small-integer option.
(ISA_3_0_MASKS_IEEE): Likewise.
(OTHER_VSX_VECTOR_MASKS): Likewise.
(POWERPC_MASKS
generated. This isn't surprising because it isn't something that auto
vectorization might generate by default.
[gcc]
2017-07-27 Michael Meissner
PR target/81593
* config/rs6000/rs6000-protos.h (rs6000_emit_xxpermdi): New
declaration.
* config/rs600
On Fri, Jul 28, 2017 at 09:51:30AM +0200, Richard Biener wrote:
> On Fri, Jul 28, 2017 at 1:21 AM, Michael Meissner
> wrote:
> > This patches optimizes the PowerPC vector set operation for 64-bit doubles
> > and
> > longs where the elements in the vector set may
On Fri, Jul 28, 2017 at 04:08:50PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jul 27, 2017 at 07:21:14PM -0400, Michael Meissner wrote:
> > This patches optimizes the PowerPC vector set operation for 64-bit doubles
> > and
> > longs where the elements in t
? "mtvsrdd %x0,%1,%2"
> >>: "mtvsrdd %x0,%2,%1");
> >
> > This one could be
> >
> > {
> > if (!BYTES_BIG_ENDIAN)
>
> !VECTOR_ELT_ORDER_BIG (to accommodate -maltivec=be). (We have some general
> bitrot associated
w).
...
> In this and the other testcase, should you test no other insns at all
> are generated?
Here are the revised patches. I tested on a little endian power8 system and a
big endian power7 system. Are these patches ok for the trunk?
[gcc]
2017-08-02 Michael Meissner
PR targ
On Thu, Aug 03, 2017 at 10:01:41AM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Wed, Aug 02, 2017 at 10:28:55AM -0400, Michael Meissner wrote:
> > On Fri, Jul 28, 2017 at 04:08:50PM -0500, Segher Boessenkool wrote:
> > > I think calling this with the rtx elementN a
On Thu, Aug 03, 2017 at 10:01:41AM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Wed, Aug 02, 2017 at 10:28:55AM -0400, Michael Meissner wrote:
> > On Fri, Jul 28, 2017 at 04:08:50PM -0500, Segher Boessenkool wrote:
> > > I think calling this with the rtx elementN a
we can easily enable or disable
__float128, just by defining or undefining the macro.
I also fixed two of the original __float128 test cases to not use the
-static-libgcc option.
I've tested this patch on big endian power7 (both 32/64-bits) and little endian
power8 (just 64-bits). Can I co
t floating
point, you would want that.
2017-08-15 Michael Meissner
PR libquadmath/81848
* configure.ac (powerpc*-linux*): Use attribute mode KC to create
complex __float128 on PowerPC instead of attribute mode TC.
* quadmth.h (__complex128): Likewise.
*
On Wed, Aug 16, 2017 at 01:46:12AM +, Joseph Myers wrote:
> ENOPATCH
2017-08-15 Michael Meissner
PR libquadmath/81848
* configure.ac (powerpc*-linux*): Use attribute mode KC to create
complex __float128 on PowerPC instead of attribute mode TC.
* quadmt
128 as the
default, and there were no changes. I also built and ran spec 2006 FP tests
with the two compilers, and there no changes in runtime of the tests.
Can I check this into the trunk once the patch for 81848 has been applied?
[gcc]
2017-08-16 Michael Meissner
PR target/81872
This patch deletes some of the debug switches that I've added over the years,
and now don't use any more.
I did bootstrap builds and make check runs on a little endian power8 system.
There were no regressions. Can I check this into the trunk?
2017-08-17 Michael Meissner
Ping:
2017-08-15 Michael Meissner
PR libquadmath/81848
* configure.ac (powerpc*-linux*): Use attribute mode KC to create
complex __float128 on PowerPC instead of attribute mode TC.
* quadmth.h (__complex128): Likewise.
* configure: Regenerate
endian power8 system and
there were no regressions in the tests. Can I check it into the trunk?
[gcc]
2017-08-23 Michael Meissner
* config/rs6000/rs6000.opt (-mpower9-dform-scalar): Delete
undocumented switches.
(-mpower9-dform-vector): Likewise.
(-mpower9-dform
check
this patch into the trunk and back port it GCC 7? GCC 6 did not have the
optimization.
[gcc]
2017-08-28 Michael Meissner
PR target/81959
* config/rs6000/rs6000.md (float_si2_hw): If register
allocation hasn't been done, make sure the memory address is
X
tivec register.
[gcc]
2017-08-28 Michael Meissner
PR target/82015
* config/rs6000/rs6000.c (rs6000_expand_binop_builtin): Insure
that the second argument of the built-in functions to unpack
128-bit scalar types to 64-bit values is 0 or 1. Change to use a
On Tue, Aug 29, 2017 at 06:14:37AM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Mon, Aug 28, 2017 at 02:50:02PM -0400, Michael Meissner wrote:
> > When I added the optimization for loading 32-bit values directly into the
> > vector registers from memory to convert to
Bill Seurer pointed out to me that when I checked in the PR 82015 patches, I
had changed the error message, but I didn't update the test. I checked this
patch in as obvious:
2017-08-30 Michael Meissner
PR target/82015
* gcc.target/powerpc/pr82015.c: Fix up error me
On Wed, Aug 30, 2017 at 01:11:51AM +0200, Jakub Jelinek wrote:
> On Tue, Aug 15, 2017 at 11:06:01PM -0400, Michael Meissner wrote:
> > 2017-08-15 Michael Meissner
> >
> > PR libquadmath/81848
> > * configure.ac (powerpc*-linux*): Use attribute mode K
, little endian, --with-cpu=power8
* Power9 prototype bootstrap, little endian, --with-cpu=power9
Can I check these patches into the trunk?
[gcc]
2017-09-06 Michael Meissner
* config/rs6000/rs6000-cpus.def (OTHER_VSX_VECTOR_MASKS): Delete
OPTION_MASK_FLOAT128_KEYWORD
using a peephole2 to
load the offset value into a GPR and doing an indexed store. I have code for
PR 80510 that I will submit after this patch. That patch needs this patch to
prevent using direct move to do a store.
Is this patch ok for GCC 8? How about GCC 7.2?
[gcc]
2017-05-05 Michael Meissner
bootstraps and make check tests on both x86_64 and PowerPC and
there were no regressions. On the PowerPC, I included my initial
implementation of the target_clones support, but those patches are not part of
this patch submission.
Can I check this into the trunk?
2017-05-10 Michael Meissner
l the
register allocator to load up the offset into a register, instead of doing the
move/store. I tried various modifications to secondary reload, but I wasn't
able to get it to change behavor.
[gcc]
2017-05-12 Michael Meissner
PR target/80510
* config/rs6000/pre
trunk, and later apply it to the GCC 7 and 6
branches?
[gcc]
2017-05-22 Michael Meissner
PR target/80718
* config/rs6000/vsx.md (vsx_splat_, VSX_D iterator): Split
V2DF/V2DI splat into two separate patterns, one that handles
registers, and the other that only
regressions. Can I install it into the trunk?
[gcc]
2017-05-24 Michael Meissner
* config/rs6000/rs6000.c (toplevel): Include attribs.h.
(enum clone_list): New enumeration to give the target clones
processors we generate code for.
(rs6000_clone_map): New array to
On Thu, May 25, 2017 at 09:56:20PM +0200, Florian Weimer wrote:
> On Thu, May 25, 2017 at 8:25 PM, Michael Meissner
> wrote:
> > This patch adds the initial attribute((target_clone(...))) support to the
>
> Patch seems to be missing.
>
> Florian
>
Sorry about
On Tue, May 30, 2017 at 04:51:34PM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Thu, May 25, 2017 at 04:05:39PM -0400, Michael Meissner wrote:
> > +/* On PowerPC, we have a limited number of target clones that we care about
> > + which means we can use an array to hol
ped this on a little endian power8 system and there were no
regressions. Can I install this in the trunk?
[gcc]
2017-05-31 Michael Meissner
* config/rs6000/rs6000.c (toplevel): Include attribs.h.
(CLONE_*): New constants to define the processors we can generate
code for w
On Wed, May 31, 2017 at 06:33:37PM -0400, Michael Meissner wrote:
> Here is the updated version of the target_clone attribute support.
>
> The changes include:
>
> 1) Change the order of the CLONE priority list from default being 0 to ISA 3.0
> being the highest (and elimin
On Thu, Jun 01, 2017 at 03:43:22PM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Wed, May 31, 2017 at 06:33:37PM -0400, Michael Meissner wrote:
> > +/* On PowerPC, we have a limited number of target clones that we care about
> > + which means we can use an array to hol
On Fri, Jun 02, 2017 at 11:55:57AM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Jun 02, 2017 at 10:16:27AM -0400, Michael Meissner wrote:
> > > With "you don't have to give the enum a name" I meant write it as
> > >
> > > enum
wing it at SPEC2k6 now.
I was going to apply to the PowerPC and do a spec run but the patch for
tree-vect-loop.c doesn't apply. Could you regenerate the patch, and also tell
me the subversion id it is based off of?
Thanks in advance.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street
false,
+ profile_count::uninitialized ());
cgraph_node::add_new_function (decl, true);
symtab->call_cgraph_insertion_hooks (cgraph_node::get_create (decl));
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet
these
patches. Can I install them into the trunk?
2016-12-23 Michael Meissner
* config/rs6000/predicates.md (const_0_to_12_operand): Rename
predicate and change test from 0..11 to 0..12 to match the
semantics of the word extract/insert instructions. Change all
ca
On Fri, Dec 23, 2016 at 04:34:10PM -0600, Segher Boessenkool wrote:
> On Fri, Dec 23, 2016 at 04:47:22PM -0500, Michael Meissner wrote:
> > I had two thinkos in my previous patches for ISA 3.0 (power9) support that
> > both
> > relate to word extraction and insertion.
>
Thanks. I fixed the error messages.
--
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
.
[gcc]
2016-12-29 Michael Meissner
PR target/71977
PR target/70568
PR target/78823
* config/rs6000/predicates.md (sf_subreg_operand): New predicate
to return true if the operand contains a SUBREG mixing SImode and
SFmode on 64-bit VSX syste
period?
2016-12-30 Michael Meissner
PR target/78900
* config/rs6000/rs6000.c (rs6000_split_signbit): Change some
assertions. Add support for doing the signbit if the IEEE 128-bit
floating point value is in a GPR.
* config/rs6000/rs6000.md (Fsignbit
r, it needs to use a traditional Altivec register.
The following patch fixes this:
[gcc]
2017-01-03 Michael Meissner
PR target/78953
* config/rs6000/vsx.md (vsx_extract__store_p9): If we are
extracting SImode to a GPR register so that we can generate a
store,
On Wed, Jan 04, 2017 at 02:17:16PM -0500, David Edelsohn wrote:
> On Thu, Dec 29, 2016 at 7:24 PM, Michael Meissner
> wrote:
>
> Mike,
>
> Thanks for the tremendous effort on this patch. A few comments.
>
> The ChangeLog contains a lot of extraneous commentary
M double double constants, and all of the decimal reload gunk.
> Okay with those changes. This change is too invasive for GCC 6
> backport at this late phase of GCC 6 release.
>
> We'll see if Segher catches anything additional when he wants some
> light reading. :-)
>
&
power8 system and using an assembler that knows about ISA 3.0
instructions. I added a new test to verify the results. Can I check this into
the trunk? This is not an issue on GCC 6.x.
[gcc]
2017-01-09 Michael Meissner
PR target/79004
* config/rs6000/rs6000.md (FP_ISA3): Do not
801 - 900 of 1951 matches
Mail list logo
