> On Sep 12, 2017, at 10:00 AM, Segher Boessenkool
> wrote:
>
> Hi Jakub,
>
> On Tue, Sep 12, 2017 at 04:25:48PM +0200, Jakub Jelinek wrote:
>> On Thu, Sep 07, 2017 at 10:40:30AM +0200, Jakub Jelinek wrote:
>>> The C and C++ FE handle resolve_overloaded_builtin differently, the C FE
>>> calls
> On Sep 12, 2017, at 9:41 AM, Will Schmidt wrote:
>
> Hi
>
> [PATCH, rs6000] Folding of vector loads in GIMPLE
>
> Folding of vector loads in GIMPLE.
>
> - Add code to handle gimple folding for the vec_ld builtins.
> - Remove the now obsoleted folding code for vec_ld from rs6000-c.c.
> Surr
> On Sep 12, 2017, at 4:08 PM, Will Schmidt wrote:
>
> Hi,
>
> [PATCH, rs6000] [v2] Folding of vector loads in GIMPLE
>
> Folding of vector loads in GIMPLE.
>
> Add code to handle gimple folding for the vec_ld builtins.
> Remove the now obsoleted folding code for vec_ld from rs6000-c.c. Surro
On Sep 13, 2017, at 7:23 AM, Richard Biener wrote:
>
> On Tue, Sep 12, 2017 at 11:08 PM, Will Schmidt
> wrote:
>> Hi,
>>
>> [PATCH, rs6000] [v2] Folding of vector loads in GIMPLE
>>
>> Folding of vector loads in GIMPLE.
>>
>> Add code to handle gimple folding for the vec_ld builtins.
>> Remov
On Sep 13, 2017, at 10:40 AM, Bill Schmidt wrote:
>
> On Sep 13, 2017, at 7:23 AM, Richard Biener
> wrote:
>>
>> On Tue, Sep 12, 2017 at 11:08 PM, Will Schmidt
>> wrote:
>>> Hi,
>>>
>>> [PATCH, rs6000] [v2] Folding of vector load
On Sep 14, 2017, at 5:15 AM, Richard Biener wrote:
>
> On Wed, Sep 13, 2017 at 10:14 PM, Bill Schmidt
> wrote:
>> On Sep 13, 2017, at 10:40 AM, Bill Schmidt
>> wrote:
>>>
>>> On Sep 13, 2017, at 7:23 AM, Richard Biener
>>> wrote:
>>&
On Sep 15, 2017, at 4:13 AM, Richard Biener wrote:
>
> On Thu, Sep 14, 2017 at 4:38 PM, Bill Schmidt
> wrote:
>> On Sep 14, 2017, at 5:15 AM, Richard Biener
>> wrote:
>>>
>>> On Wed, Sep 13, 2017 at 10:14 PM, Bill Schmidt
>>> wrote:
egressions.
Is this ok for trunk?
Thanks!
Bill
[gcc]
2017-09-19 Bill Schmidt
PR tree-optimization/82255
* tree-vect-stmts.c (vect_model_load_cost): Don't count
vec_construct cost when a true strided load isn't present.
[gcc/testsuite]
2017-09-19 Bill S
On 9/19/17 12:38 PM, Bill Schmidt wrote:
> Hi,
>
> https://gcc.gnu.org/PR82255 identifies a problem in the vector cost model
> where a vectorized load is treated as having the cost of a strided load
> in a case where we will not actually generate a strided load. This is
>
Hi Kelvin,
This is in quite good shape. In addition to Segher's comments, I have a few
questions/requests below.
> On Sep 15, 2017, at 4:04 PM, Kelvin Nilsen
> wrote:
>
> @@ -385,6 +396,25 @@ const_load_sequence_p (swap_web_entry *insn_entry,
> split_const (XVECEXP (tocrel_base, 0, 0)
On Sep 19, 2017, at 3:58 PM, Richard Sandiford
wrote:
>
> Bill Schmidt writes:
>> Index: gcc/tree-vect-stmts.c
>> ===
>> --- gcc/tree-vect-stmts.c(revision 252760)
>> +++ gcc/tree-vect-stmts.c
On Sep 19, 2017, at 4:21 PM, Bill Schmidt wrote:
>
> On Sep 19, 2017, at 3:58 PM, Richard Sandiford
> wrote:
>>
>> Bill Schmidt writes:
>>> Index: gcc/tree-vect-stmts.c
>>> ===
>>&
On Sep 20, 2017, at 3:49 AM, Richard Sandiford
wrote:
>
> Bill Schmidt writes:
>> On Sep 19, 2017, at 4:21 PM, Bill Schmidt
>> wrote:
>>> On Sep 19, 2017, at 3:58 PM, Richard Sandiford
>>> wrote:
>>>> Bill Sch
On Sep 20, 2017, at 3:49 AM, Richard Sandiford
wrote:
>
> But I think this shows up another problem. In the vectorised loop,
> we have 1 copy of the load and 4 copies of the ABS (after unpacking).
> But vect_analyze_slp_cost_1 is being called with ncopies_for_cost == 4
> even for the loads. So
On Sep 20, 2017, at 2:14 PM, Bill Schmidt wrote:
>
> On Sep 20, 2017, at 3:49 AM, Richard Sandiford
> wrote:
>>
>> But I think this shows up another problem. In the vectorised loop,
>> we have 1 copy of the load and 4 copies of the ABS (after unpacking).
>&g
On Sep 21, 2017, at 2:37 AM, Richard Biener wrote:
>
> On Wed, Sep 20, 2017 at 9:17 PM, Bill Schmidt
> wrote:
>> On Sep 20, 2017, at 2:14 PM, Bill Schmidt
>> wrote:
>>>
>>> On Sep 20, 2017, at 3:49 AM, Richard Sandiford
>>> wrote:
>>&
On Sep 22, 2017, at 5:27 AM, Richard Biener wrote:
>
> On Thu, Sep 21, 2017 at 10:56 PM, Will Schmidt
> wrote:
>> Hi,
>>
>> Folding of vector stores in GIMPLE.
>>
>> - Add code to handle gimple folding for the vec_st (vector store) builtins.
>> - Remove the now obsoleted folding code for vec_s
On Sep 26, 2017, at 5:57 AM, Segher Boessenkool
wrote:
>
>> +/* { dg-final { scan-assembler-not "swap" } } */
>
> So what is this really testing for? xxswapd? But a) we never generate
> that, and b) you could use a better regex?
Agreed, this looks like an unnecessary test for now. Changing
eleases after a
short wait.
Thanks,
Bill
2017-09-26 Bill Schmidt
PR tree-optimization/82337
* gimple-ssa-strength-reduction.c (find_phi_def): Don't record a
phi definition if the PHI result appears in an abnormal PHI.
(find_basis_for_base_expr): Don
done. This patch fixes that.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is
this ok for trunk?
Thanks,
Bill
2017-10-04 Bill Schmidt
* config/rs6000/rs6000-p8swap.c (rs6000_analyze_swaps): Process
deferred rescans after the lvx/stvx recombination pre
> On Jan 26, 2017, at 6:40 PM, Segher Boessenkool
> wrote:
>
> On Thu, Jan 26, 2017 at 05:31:16PM -0600, Bill Schmidt wrote:
>>> So for older targets it used to run the final, but not after the patch; and
>>> for newer targets it used to not run it, but it does
thereafter for GCC 6?
Thanks,
Bill
[gcc]
2017-01-29 Bill Schmidt
PR target/79268
* config/rs6000/altivec.h (vec_xl): Revise #define.
(vec_xst): Likewise.
[gcc/testsuite]
2017-01-29 Bill Schmidt
PR target/79268
* gcc.target/powerpc/pr79268.c: New
Thanks,
Bill
2017-02-01 Bill Schmidt
* gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c: Adjust test
conditions.
Index: gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c
===
--- gcc/testsuite/gcc.d
ested on powerpc64[le]-unknown-linux-gnu with no regressions
in either environment. Is this ok for trunk, and after a suitable period, for
backport to GCC 5 and 6?
Thanks,
Bill
[gcc]
2017-02-16 Bill Schmidt
PR target/79261
* config/rs6000/rs6000.c (rs6000_expand_ternop_bui
Hi,
As discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68644,
the test case gcc.dg/tree-ssa/ivopts-lt-2.c does not apply to POWER
targets, as the cost model properly shows the pre-increment approach
to be preferable and results in ideal code generation. Thus, adding
powerpc*-*-* to the
, adding
powerpc*-*-* to the list of targets to skip for this test.
Verified on powerpc64le-unknown-linux-gnu. Is this ok for trunk?
Thanks,
Bill
2017-02-22 Bill Schmidt
PR tree-optimization/68644
* gcc.dg/tree-ssa/ivopts-lt-2.c: Skip for powerpc*-*-*.
Index: gcc/testsuite
Thanks, Jeff -- I caught it as soon as I hit the stupid button... :)
> On Feb 22, 2017, at 11:56 AM, Jeff Law wrote:
>
> On 02/22/2017 10:54 AM, Bill Schmidt wrote:
>> Hi,
>>
>> As discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68644,
>> the test c
2017-03-01 Bill Schmidt
* doc/invoke.texi: Document default code model for 64-bit Linux.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 245811)
+++ gcc/doc/invoke.texi (working copy)
@@ -21166,7 +21
Hi Andreas,
We discovered the problem this morning in-house and are working on a patch.
-- Bill
Bill Schmidt, Ph.D.
GCC for Linux on Power
Linux on Power Toolchain
IBM Linux Technology Center
wschm...@linux.vnet.ibm.com
> On Mar 2, 2017, at 11:25 AM, Andreas Schwab wrote:
>
>
uninitialized. Bootstrapped and tested
on powerpc64le-unknown-linux-gnu, committed as obvious.
Thanks,
Bill
2017-03-02 Bill Schmidt
* config/rs6000/vector.md (vector_ne__p): Correct operand
numbers.
(vector_ae__p): Likewise.
(vector_nez__p): Likewise
Fixed as r245849. Thanks...
-- Bill
Bill Schmidt, Ph.D.
GCC for Linux on Power
Linux on Power Toolchain
IBM Linux Technology Center
wschm...@linux.vnet.ibm.com
> On Mar 2, 2017, at 11:33 AM, Bill Schmidt wrote:
>
> Hi Andreas,
>
> We discovered the problem this morning i
uncertain whether we should backport the fix to gcc 5 and 6, since,
although the code is technically incorrect, it works just fine. The fix
is needed in trunk to permit the sanity checking that Jakub has proposed
for genrecog.
Thanks,
Bill
2017-03-08 Bill Schmidt
* config/rs6000/rs6000.c
> On Mar 6, 2017, at 6:55 AM, Jakub Jelinek wrote:
>
> Nice. So just arm, aarch64 and rs6000 to go.
Proposed patch for rs6000 is here:
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00372.html.
Thanks,
Bill
This was not
clear in the original text, so I'd appreciate confirmation or
correction on this point.
The PDF seems to build properly and I don't see any visible errors.
Is this ok for trunk?
Thanks,
Bill
2017-03-09 Bill Schmidt
* doc/extend.texi (6.11 Additional Floating Ty
it seems to be something
we can do without. It does not appear in the built-in table in rs6000-c.c All
the entries in that built-in table are type-correct with respect to the above
definitions. We should delete that entry from rs6000-builtin.def.
-- Bill
Bill Schmidt, Ph.D.
GCC for Linux on
Just so there's no duplication of effort -- I'll follow up with a patch to
remove the
outdated built-in.
-- Bill
Bill Schmidt, Ph.D.
GCC for Linux on Power
Linux on Power Toolchain
IBM Linux Technology Center
wschm...@linux.vnet.ibm.com
> On Mar 10, 2017, at 8:24 AM, Bill S
Hi,
Jakub observed that these built-ins are no longer reachable (and
haven't been for quite a while). Time to chuck them out.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with
(surprise!) no regressions. Is this ok for trunk?
Thanks,
Bill
2017-03-10 Bill Sc
Thanks! Committed in revision 246046.
> On Mar 10, 2017, at 1:14 PM, Segher Boessenkool
> wrote:
>
> On Fri, Mar 10, 2017 at 12:16:31PM -0600, Bill Schmidt wrote:
>> Jakub observed that these built-ins are no longer reachable (and
>> haven't been for quite a wh
nough.
Revised patch below. Is this ok for trunk?
Thanks,
Bill
2017-03-13 Bill Schmidt
* doc/extend.texi (6.11 Additional Floating Types): Revise.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 246014)
++
> On Mar 13, 2017, at 6:31 PM, Segher Boessenkool
> wrote:
>
> Hi Bill,
>
> On Mon, Mar 13, 2017 at 01:11:01PM -0500, Bill Schmidt wrote:
>> Index: gcc/doc/extend.texi
>> ===
>> --- gcc/d
looks fine afterward. Bootstrapped and tested
on powerpc64le-unknown-linux-gnu with no regressions. Is this ok
for trunk?
Thanks,
Bill
[gcc]
2017-03-13 Bill Schmidt
PR tree-optimization/79908
* tree-stdarg.c (expand_ifn_va_arg_1): Don't force something to be
an l
> On Mar 14, 2017, at 3:57 AM, Richard Biener
> wrote:
>
> On Tue, Mar 14, 2017 at 1:04 AM, Bill Schmidt
> wrote:
>>
>> Index: gcc/tree-stdarg.c
>> ===
>> --- gcc/tree-stdarg.c (re
> On Mar 14, 2017, at 7:50 AM, Bill Schmidt wrote:
>
>
>> On Mar 14, 2017, at 3:57 AM, Richard Biener
>> wrote:
>>
>> On Tue, Mar 14, 2017 at 1:04 AM, Bill Schmidt
>> w
> On Mar 14, 2017, at 9:25 AM, Richard Biener
> wrote:
>
> On Tue, Mar 14, 2017 at 3:20 PM, Bill Schmidt
> wrote:
>>
>>> On Mar 14, 2017, at 7:50 AM, Bill Schmidt
>>> wrote:
>>>
>>>
>>>> On Mar 14, 2017, at 3:57 AM, Ri
On Mar 14, 2017, at 9:32 AM, Bill Schmidt wrote:
>
>> On Mar 14, 2017, at 9:25 AM, Richard Biener
>> wrote:
>>
>>>>> Better is sth like
>>>>>
>>>>> Index: gcc/tree-stdarg.c
>>>>> ==
> On Mar 14, 2017, at 11:07 AM, Bill Schmidt
> wrote:
>>
>> Your suggestion failed bootstrap in libiberty on vprintf-support.c.
>> Compilation failed with:
>>
>> /home/wschmidt/gcc/build/gcc-mainline-test2-debug/gcc/xgcc
>> -B/home/wschmidt/gcc/
> On Mar 14, 2017, at 9:25 AM, Richard Biener
> wrote:
>
> On Tue, Mar 14, 2017 at 3:20 PM, Bill Schmidt
> wrote:
>>
>>> On Mar 14, 2017, at 7:50 AM, Bill Schmidt
>>> wrote:
>>>
>>>
>>>> On Mar 14, 2017, at 3:57 AM, Ri
Hi,
> On Mar 17, 2017, at 6:44 AM, Richard Biener
> wrote:
>
> No, I was confused in thinking gimplify_expr would handle the case
> properly. For
> just gimplifying side-effects we should use the middle-end
> gimplification machinery:
>
> Index: tree-stdarg.c
> ===
> On Mar 17, 2017, at 9:52 AM, Bill Schmidt wrote:
>
> Hi,
>
>> On Mar 17, 2017, at 6:44 AM, Richard Biener
>> wrote:
>>
>> No, I was confused in thinking gimplify_expr would handle the case
>> properly. For
>> just gimplifying side-effect
Joseph, any further comments, or may I commit this?
Thanks!
Bill
> On Mar 13, 2017, at 6:31 PM, Segher Boessenkool
> wrote:
>
> Hi Bill,
>
> On Mon, Mar 13, 2017 at 01:11:01PM -0500, Bill Schmidt wrote:
>> In
ccurs.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. I'll plan to commit this on Monday if there are no
comments.
Thanks,
Bill
[gcc]
2017-03-17 Bill Schmidt
PR tree-optimization/80054
* gimple-ssa-strength-reduction.c (all_phi_incrs_profita
blems there, is this patch ok for trunk? I suppose
technically it should be queued up for GCC 7, though it seems harmless
enough for GCC 6. Please let me know which you would prefer.
Thanks!
Bill
2016-03-06 Bill Schmidt
* lib/target-support
Thanks,
Bill
2016-03-28 Bill Schmidt
* g++.dg/guality/guality.exp: Disable for powerpc*-linux*.
* gcc.dg/guality/guality.exp: Likewise.
Index: gcc/testsuite/g++.dg/guality/guality.exp
===
--- gcc/test
Hi Jakub,
On Tue, 2016-03-29 at 08:53 +0200, Jakub Jelinek wrote:
> On Mon, Mar 28, 2016 at 07:38:46PM -0500, Bill Schmidt wrote:
> > For a long time we've had hundreds of failing guality tests. These
> > failures don't seem to have any correlation with gdb functionalit
Hi Jakub,
Thanks for the information; I really do appreciate it!
On Tue, 2016-03-29 at 17:33 +0200, Jakub Jelinek wrote:
> On Tue, Mar 29, 2016 at 08:19:39AM -0500, Bill Schmidt wrote:
> > When you say that "the debug info quality is already pretty bad on
> > powerpc*,&quo
Thanks to all for the helpful explanations. We plan to leave things as
they are. I hope someday we can make some time to do some basic
investigations here.
Bill
On Fri, 2016-04-01 at 00:09 -0500, Aldy Hernandez wrote:
> Richard Biener writes:
>
> > Hell, even slapping a xfail powerpc*-*-* on
larly to what is done elsewhere in tree-ssa-math-opts.c.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu, with no
regressions. Is this ok for trunk, as well as for backport to 5 and
4.9?
Thanks,
Bill
[gcc]
2016-04-03 Bill Schmidt
Jakub Jelinek
* tree-inl
On Sun, 2016-04-03 at 18:43 -0500, Bill Schmidt wrote:
> Hi,
>
> PR70457 shows that we ICE if a call to pow() has only one argument, or
> more generally doesn't match its expected signature. This can happen
> both during the widen-mult phase and the tree-inline phase. As
OK, sorry for misreading the note. This is exactly what I've done for
the GCC 5 and GCC 4.9 versions, so I'll update the GCC 6 version to do
the same.
Bill
On Mon, 2016-04-04 at 08:57 +0200, Jakub Jelinek wrote:
> On Sun, Apr 03, 2016 at 06:43:47PM -0500, Bill Schmidt wrote:
f the
affected functions.
All have passed regstrap on powerpc64le-unknown-linux-gnu. Are these
ok?
Thanks,
Bill
Trunk
=
[gcc]
2016-04-04 Bill Schmidt
Jakub Jelinek
PR middle-end/70457
* tree-inline.c (estimate_num_insn): Use gimple_call_builtin_p
to ens
On Thu, 2016-04-14 at 13:22 +0200, Richard Biener wrote:
> The following fixes PR70130 - improved SLP capabilities now run into
> the realignment code on ppc which doesn't properly verify that all
> vector loads emitted by vectorizable_load share the same alignment.
>
> Bootstrap / regtest pending
ave to just apologize for the size and leave it at that. Sorry! :)
Bootstrapped and tested successfully on powerpc64le-unknown-linux-gnu,
and on powerpc64-unknown-linux-gnu (-m32 and -m64) with no regressions.
Is this ok for trunk after GCC 6 releases?
Thanks,
Bill
2016-04-18 Bill Schmidt
On Tue, 2016-04-19 at 10:09 +0200, Richard Biener wrote:
> On Tue, Apr 19, 2016 at 12:05 AM, Bill Schmidt
> wrote:
> > Hi,
> >
> > Expanding built-ins in the usual way (leaving them as calls until
> > expanding into RTL) restricts the amount of optimization that ca
On Tue, 2016-04-19 at 10:09 +0200, Richard Biener wrote:
> On Tue, Apr 19, 2016 at 12:05 AM, Bill Schmidt
> wrote:
> > Hi,
> >
> > Expanding built-ins in the usual way (leaving them as calls until
> > expanding into RTL) restricts the amount of optimization that ca
On Tue, 2016-04-19 at 08:10 -0500, Bill Schmidt wrote:
> On Tue, 2016-04-19 at 10:09 +0200, Richard Biener wrote:
> >
> > x86 nowadays has intrinsics implemented as inlines - they come from
> > header files. It seems for ppc the intrinsics are somehow magically
> &g
th no regressions. Is this ok for trunk
after GCC 6 releases?
Thanks,
Bill
On Tue, 2016-04-19 at 10:09 +0200, Richard Biener wrote:
> On Tue, Apr 19, 2016 at 12:05 AM, Bill Schmidt
> wrote:
> > Hi,
> >
> > Expanding built-ins in the usual way (leaving them as calls until
>
nu with no regressions. Is this ok for
trunk, following GCC 6 release?
Thanks,
Bill
[gcc]
2016-04-24 Bill Schmidt
* config/rs6000/rs6000-builtin.def (STXVD2X_V1TI): Fix target
built-in function name.
(STXVD2X_V2DF): Likewise.
(STXVD2X_V2DI)
On Sun, 2016-04-24 at 15:52 -0500, Segher Boessenkool wrote:
> On Sun, Apr 24, 2016 at 02:06:47PM -0500, Bill Schmidt wrote:
> > ISA 3.0 adds the lvxh8x, lvxb16x, stvxh8x, and stvxb16x instructions,
>
> lxvh8x etc. It looks like you only swapped things in this message,
> not i
end not to be used anyway because the vec_st interface is friendlier,
but we should clean this up. Is that ok?
Thanks,
Bill
2016-04-25 Bill Schmidt
* rs6000-builtin.def: Correct pasto error for stxvd2x and stxvw4x
built-in functions.
Index: gcc/config/rs6000/rs6000-b
On Mon, 2016-04-25 at 17:06 +0200, Jakub Jelinek wrote:
> On Mon, Apr 25, 2016 at 09:09:03AM -0500, Bill Schmidt wrote:
> > Hi Segher,
> >
> > Here's the fix for the obvious pasto separated out. CCing Richi and
> > Jakub as I'd appreciate release manager
ttern.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. Ok for trunk, and eventual backport to 6 and 5 branches?
Thanks,
Bill
[gcc]
2016-09-16 Bill Schmidt
PR target/77613
* config/rs6000/rs6000.c (rtx_is_swappable_p): Add support for
splat
On Sep 28, 2016, at 10:54 AM, Kyrill Tkachov
wrote:
>
> Hi all,
>
> This is v4 of the pass. It addresses feedback by Bernhard, including typo
> fixes and
> skipping of debug statements.
> Also, I've extended it to handle the case from PR 23684 and included that
> testcase
> in the patch. Mer
unities, I have not yet found a place where this changes code
generation.
Bootstrapped and tested for powerpc64le-unknown-linux-gnu with no regressions,
committed.
Thanks,
Bill
2016-10-10 Bill Schmidt
PR tree-optimization/77824
* gimple-ssa-strength-reduction.c
was inadequate. This patch replaces it with the correct check, determining
whether the type of the candidate is a pointer type.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu, committed.
Thanks,
Bill
2016-10-12 Bill Schmidt
PR tree-optimization/77937
* gimple-ssa
to
estimate the cost for the rare case where it can be useful.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions, committed.
Thanks,
Bill
2016-10-13 Bill Schmidt
PR tree-optimization/77937
* gimple-ssa-strength-reduction.c (analyze_increments): Set
Here are torture test cases for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937. Markus Trippelsdorf
kindly provided the source for the tests and verified the correct
dejagnu options on x86_64-pc-linux-gnu. Committed.
Thanks,
Bill
2016-10-13 Bill Schmidt
PR tree-optimization
Hi Richard,
> On Oct 14, 2016, at 4:19 AM, Richard Biener
> wrote:
>
> On Thu, Oct 13, 2016 at 5:38 PM, Bill Schmidt
> wrote:
>> The previous patch for
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937 is necessary, but not
>> sufficient in all cases
gcc.gnu.org/bugzilla/show_bug.cgi?id=77937. Markus Trippelsdorf
>>> kindly provided the source for the tests and verified the correct
>>> dejagnu options on x86_64-pc-linux-gnu. Committed.
>>>
>>> Thanks,
>>> Bill
>>>
>>>
>>
> On Oct 17, 2016, at 3:27 AM, Richard Biener
> wrote:
>
> On Fri, Oct 14, 2016 at 3:51 PM, Bill Schmidt
> wrote:
>> Hi Richard,
>>
>>> On Oct 14, 2016, at 4:19 AM, Richard Biener
>>> wrote:
>>>
>>> On Thu, Oct 13, 2016 a
> On Oct 17, 2016, at 12:26 PM, Bin.Cheng wrote:
>
> On Sat, Oct 15, 2016 at 3:07 AM, kugan
> wrote:
>> Hi Bin,
>>
>> On 15/10/16 00:15, Bin Cheng wrote:
>>>
>>> +/* Test for likely overcommitment of vector hardware resources. If a
>>> + loop iteration is relatively large, and too large a
regressions, committed.
Thanks,
Bill
[gcc]
2016-10-17 Bill Schmidt
PR tree-optimization/77916
* gimple-ssa-strength-reduction.c (create_add_on_incoming_edge):
Don't allow a MINUS_EXPR for pointer arithmetic for either known
or unknown strides.
(record_incr
Whoops. Discovered I had inadvertently left in a comment that made no
sense when fixing PR77916. This patch removes it. Committed as obvious.
Thanks,
Bill
2016-10-17 Bill Schmidt
* gimple-ssa-strength-reduction.c (record_increment): Remove
garbage comment.
Index: gcc
On Tue, 2016-10-18 at 05:13 +0200, Markus Trippelsdorf wrote:
> On 2016.10.17 at 17:23 -0500, Bill Schmidt wrote:
> > Hi,
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77916 identifies a situation
> > where SLSR will ICE when exposed to a cast from integer to po
Hi,
The previous solution for PR77916 was inadequately tested, for which I
sincerely apologize. I've reinstated the stopgap fix previously
reverted, as follows.
Thanks for your patience,
Bill
2016-10-18 Bill Schmidt
PR tree-optimization/77916
* gimple-ssa-str
On Tue, 2016-10-18 at 15:30 +0200, Markus Trippelsdorf wrote:
> I you wish I can send you a tarball with the preprocessed *.i files from
> ffmpeg, so that you can use a stage1 cross on them.
>
That would be very helpful, thanks!
Bill
ensure there are no more of these issues lurking there.
That has been a fertile environment for these kinds of negative pointer
increments.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no new
regressions, committed.
Thanks,
Bill
2016-10-19 Bill Schmidt
PR tree
ializers): Introduce a cast when necessary for the
stride type. Use the stride type for the type of the initializer.
[gcc/testsuite]
2016-10-21 Bill Schmidt
PR tree-optimization/71915
* gcc.dg/tree-ssa/pr54245.c: Delete.
* gcc.dg/tree-ssa/slsr-8.c: Adjust for
Hi,
Following committed to wwwdocs per discussion in PR78095.
Thanks,
Bill
Index: htdocs/gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
On Oct 26, 2016, at 8:29 AM, Segher Boessenkool
wrote:
>
> So, you do not want to create the builtins that we expand to machine insns
> that are not supported with the -mcpu= (or other flags) in use. What does
> the ABI have to say about this?
The ABI is silent on this point. The appendix of
New file, with #defines of
OVERLOAD_2ARG_28VAR when not compiling for C++ or strict ANSI, and
two different flavors of OVERLOAD_2ARG_DECL (C++ and otherwise)
when not compiling for strict ANSI.
* config.gcc: For each triple that includes altivec.h in
>
> On Oct 31, 2016, at 5:28 PM, Bill Schmidt wrote:
>
> The other way would be to require a specific option on the command line
> to use the new dispatch mechanism. When the option is present, we would
> predefine a macro such as __PPC_FAST_VECTOR__, which would then
> On Oct 31, 2016, at 7:09 PM, Jakub Jelinek wrote:
>
> On Mon, Oct 31, 2016 at 05:28:42PM -0500, Bill Schmidt wrote:
>> The PowerPC back end loses performance on vector intrinsics, because
>> currently
>> all of them are treated as calls throughout the middle-end
On Oct 31, 2016, at 7:19 PM, Michael Meissner
wrote:
>
> 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?
>
Hundreds and hundreds of them. All of the basic operators, many of the m
powerpc64le-unknown-linux-gnu with no
regressions. Is this ok for trunk?
Thanks,
Bill
[gcc]
2016-11-01 Bill Schmidt
* config/rs6000/rs6000.c (gimple-ssa.h): New #include.
(TARGET_GIMPLE_FOLD_BUILTIN): Define as
rs6000_gimple_fold_builtin
On Nov 2, 2016, at 4:28 AM, Jakub Jelinek wrote:
>
> On Wed, Nov 02, 2016 at 10:19:26AM +0100, Richard Biener wrote:
>> On Tue, Nov 1, 2016 at 1:09 AM, Jakub Jelinek wrote:
>>> On Mon, Oct 31, 2016 at 05:28:42PM -0500, Bill Schmidt wrote:
>>>> The PowerPC bac
On Wed, 2016-06-29 at 16:37 +, Joseph Myers wrote:
> On Tue, 28 Jun 2016, Bill Schmidt wrote:
>
> > -/* { dg-do compile { target ia64-*-* i?86-*-* x86_64-*-* } } */
> > +/* { dg-do compile { target ia64-*-* i?86-*-* x86_64-*-* powerpc64*-*-* }
> > } */
> &g
nu. Is this ok for trunk, and
eventual backport to gcc-6-branch?
Thanks,
Bill
2016-06-30 Bill Schmidt
* gcc.dg/const-float128-ped.c: Require __float128 effective
target, and specify additional options for powerpc*-*-*.
* gcc.dg/const-float128.c: Likewise.
* gcc.dg/
On Thu, 2016-06-30 at 17:55 +, Joseph Myers wrote:
> On Thu, 30 Jun 2016, Bill Schmidt wrote:
>
> > +# Return 1 if the target supports __float128 at run time,
> > +# 0 otherwise.
> > +
> > +proc check_effective_target___float128_runnable { } {
>
> I&
addressed later if desired.
Tested on powerpc64[le]-unknown-linux-gnu. Is this ok for trunk, and
eventual backport to gcc-6-branch?
Thanks,
Bill
2016-07-01 Bill Schmidt
* gcc.dg/const-float128-ped.c: Require __float128 effective
target, and specify additional options for
> On Jul 1, 2016, at 2:49 PM, Joseph Myers wrote:
>
> On Fri, 1 Jul 2016, Bill Schmidt wrote:
>
>> +/* { dg-additional-options "-mfloat128 -mvsx" { target powerpc*-*-* } } */
>
> I still think you should be using { dg-add-options float128 }, via
> defi
601 - 700 of 1523 matches
Mail list logo
