I committed the following to update my email address.
Peter
* MAINTAINERS: Update my email address.
Index: MAINTAINERS
===
--- MAINTAINERS (revision 271381)
+++ MAINTAINERS (revision 271382)
@@ -286,7 +286,7 @@ loop
nother self review of the patch,
along with another round of bootstrap and regtesting which showed
no regressions. Thanks!
Peter
Now that Vlad has fixed PR69847, which was the last problem holding the
rs6000 port from switching from reload to LRA, we are ready to flip the
switch.
Is the following ok once bootstrap/regtesting on both LE and BE
(32 & 64 regtesting) comes out clean?
Peter
* config/rs6000/rs60
case we hit any bugs in the transition.
Eventually removing the switch will be nice, since it will allow
us to clean up (ie, remove!) some code in our port.
Peter
On 8/2/16 3:17 PM, Peter Bergner wrote:
Now that Vlad has fixed PR69847, which was the last problem holding the
rs6000 port from switching from reload to LRA, we are ready to flip the
switch.
Is the following ok once bootstrap/regtesting on both LE and BE
(32 & 64 regtesting) comes out c
On 8/3/16 6:03 PM, David Edelsohn wrote:
On Wed, Aug 3, 2016 at 6:59 PM, Peter Bergner wrote:
My question, is since these failures are not due to LRA, do we
want to consider the switch to LRA ok to commit or do we want to
wait until the -mvsx-timode performance bug is fixed?
Peter,
Please
On 8/3/16 6:03 PM, David Edelsohn wrote:
Please open a Bugzilla for the rs6000 backend about the vsx-timode
performance regression. The vsx-timode regression needs to be fixed
for GCC 7.
Ok, I opened https://gcc.gnu.org/PR72804 and will start debugging
the problem.
Peter
no() instead. Since uses_hard_regs_p()
may call get_final_hard_regno() with a pseudo, I have added support
for mapping those to hard reg numbers before performing the register
elimination.
This has passed bootstrap and regtesting with no regressions.
Ok for mainline?
Peter
gcc/
PR rt
Ping this patch:
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02099.html
Peter
It seems we (ok, me) forgot to document the -mhtm option for POWER.
This bootstrapped fine and the generated docs looked good.
Is this ok for trunk and the open release branches?
Peter
* doc/invoke.texi (RS/6000 and PowerPC Options): Document -mhtm and
-mno-htm.
Index: gcc/doc
On 6/7/16 12:49 PM, David Edelsohn wrote:
On Tue, Jun 7, 2016 at 1:18 PM, Peter Bergner wrote:
It seems we (ok, me) forgot to document the -mhtm option for POWER.
This bootstrapped fine and the generated docs looked good.
Is this ok for trunk and the open release branches?
Peter
?
This bug also affects the FSF 6 branch. Ok for that branch after the patch
has burned in a while on trunk and after the usual bootstrap and regtesting?
Peter
gcc/
PR target/71656
* config/rs6000/rs6000-cpus.def (ISA_3_0_MASKS_SERVER): Add
OPTION_MASK_P9_DFORM_VECTOR
On 6/27/16 3:21 PM, Segher Boessenkool wrote:
On Sat, Jun 25, 2016 at 07:14:01PM -0500, Peter Bergner wrote:
Okay for trunk, okay for 6 later. One comment:
+ if (VECTOR_MODE_P (mode)
+ && !mode_supports_vsx_dform_quad (mode))
+return false;
if (GET_CODE (addr)
On 6/27/16 8:30 PM, Peter Bergner wrote:
On 6/27/16 3:21 PM, Segher Boessenkool wrote:
On Sat, Jun 25, 2016 at 07:14:01PM -0500, Peter Bergner wrote:
Okay for trunk, okay for 6 later. One comment:
+ if (VECTOR_MODE_P (mode)
+ && !mode_supports_vsx_dform_quad (mode))
+retu
?
Peter
gcc/
* config/rs6000/ppc-auxv.h (PPC_FEATURE2_HTM_NO_SUSPEND): New define.
* config/rs6000/rs6000.c (cpu_supports_info): Use it.
gcc/testsuite/
* gcc.target/powerpc/cpu-builtin-1.c (htm-no-suspend): Add test.
Index: gcc/config/rs6000/ppc-auxv.h
On 11/6/17 4:52 PM, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Nov 06, 2017 at 11:41:39AM -0600, Peter Bergner wrote:
>> There is a new HWCAP2 bit added to the AUXV here:
>>
>> http://patchwork.ozlabs.org/patch/824764/
>>
>> This patch adds
the glibc
> patch is also waiting. You may want to wait a little bit more too.
>
> [1] https://sourceware.org/ml/libc-alpha/2017-10/msg00867.html
Ok, I'll hold off until you push your changes. Can you please ping
me when you finally commit your patch? Thanks.
Peter
s a GLIBC issue, not a GCC issue), so if
this patch is "ok", I plan on holding off on committing this, until the GLIBC
fix is committed.
Peter
* config/rs6000/float128-ifunc.c: Don't include auxv.h.
(have_ieee_hw_p): Delete function.
(SW_OR_HW) Use __builtin_
On 7/7/17 10:18 AM, Segher Boessenkool wrote:
> On Thu, Jul 06, 2017 at 04:21:48PM -0500, Peter Bergner wrote:
>> * config/rs6000/float128-ifunc.c: Don't include auxv.h.
>> (have_ieee_hw_p): Delete function.
>> (SW_OR_HW) Use __builtin_cpu_supports().
&g
On 7/7/17 4:13 PM, Peter Bergner wrote:
> On 7/7/17 10:18 AM, Segher Boessenkool wrote:
>> On Thu, Jul 06, 2017 at 04:21:48PM -0500, Peter Bergner wrote:
>>> * config/rs6000/float128-ifunc.c: Don't include auxv.h.
>>> (have_ieee_hw_p): Delete
On 7/10/17 9:48 AM, Segher Boessenkool wrote:
> On Fri, Jul 07, 2017 at 07:14:25PM -0500, Peter Bergner wrote:
>> On 7/7/17 4:13 PM, Peter Bergner wrote:
>>> On 7/7/17 10:18 AM, Segher Boessenkool wrote:
>>>> On Thu, Jul 06, 2017 at 04:21:48PM -0500, Peter Bergner
On 7/10/17 2:52 PM, Peter Bergner wrote:
> On 7/10/17 9:48 AM, Segher Boessenkool wrote:
>> On Fri, Jul 07, 2017 at 07:14:25PM -0500, Peter Bergner wrote:
>>> On 7/7/17 4:13 PM, Peter Bergner wrote:
>>>> On 7/7/17 10:18 AM, Segher Boessenkool wrote:
>>>>
n-zero chance
or you just want to be safe, you could enforce even/odd reg usage
in the ABI upfront.
Peter
mode is more natural for AARCH64 than most
> arch. that the DFP hw support for _Decimal128 on AARCH64 would take
> the values in the qN register rather than a pair of registers.
Ah, lucky you! Then nevermind. :-)
Peter
" } */
>
> With the same results as above. Note, I am running on
> perch.aus.stglabs.ibm.com which
> is a Power 9 system. Is -m32 not supported on Power 9?
-m32 is supported on POWER9, it's only not supported on little endian.
Peter
hem.
This passed bootstrap and regtesting on powerpc64le-linux with no regressions.
Ok for trunk?
Peter
gcc/
PR middle-end/81564
* tree-cfg.c (group_case_labels_stmt): Handle already deleted blocks.
gcc/testsuite/
PR middle-end/81564
* gcc.dg/pr81564.c: New test.
In
On 7/27/17 2:48 AM, Richard Biener wrote:
> On Wed, Jul 26, 2017 at 9:35 PM, Peter Bergner wrote:
>> The fix here is to just treat case labels that point to blocks that have
>> already been deleted similarly to case labels that point to the default
>> case statement, by remo
dependent on that.
Peter
This patch makes the -mlra option a nop while disallowing -mno-lra.
It also removes the target bit mask and its usage.
Finally, this patch updates the testsuite by removing all usage of
the -mlra and -mno-lra options.
This passed bootstrap and regtesting with no regressions, ok for trunk?
Peter
This patch removes reload specific code from the rs6000 port made possible
by the elimination of the usage of the -mno-lra option.
This passed bootstrap and regtesting with no regressions, ok for trunk?
Peter
* config/rs6000/predicates.md (volatile_mem_operand) Remove code
On 7/27/17 11:47 AM, Segher Boessenkool wrote:
> On Thu, Jul 27, 2017 at 10:43:44AM -0500, Peter Bergner wrote:
>> This patch makes the -mlra option a nop while disallowing -mno-lra.
>> It also removes the target bit mask and its usage.
>> Finally, this patch updates the test
On 7/27/17 2:29 PM, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jul 27, 2017 at 10:44:43AM -0500, Peter Bergner wrote:
>> This patch removes reload specific code from the rs6000 port made possible
>> by the elimination of the usage of the -mno-lra option.
>
>>
On 7/27/17 12:21 PM, Steven Bosscher wrote:
> On Wed, Jul 26, 2017 at 9:35 PM, Peter Bergner wrote:
>> The test case for PR81564 exposes an issue where the case labels for a
>> switch statement point to blocks that have already been removed by an
>> earlier call to cleanup
On 6/27/17 10:51 AM, Segher Boessenkool wrote:
> On Mon, Jun 26, 2017 at 10:33:48PM -0500, Peter Bergner wrote:
>> Tulio added support for two new AT_HWCAP2 bits to GLIBC which have been
>> recently added to the kernel:
>>
>> https://www.sourceware.org/ml/libc-
with no regressions and Mike
ran this on SPEC2006 and found no performance regressions with it.
Ok for trunk? Do we want this on the GCC 7 branch where LRA is on by default?
Peter
gcc/
* config/rs6000/vsx.md (*vsx_le_permute_): Add support for
operands residing in integer
-mlra.
This passed bootstrap and regtesting with no regressions. Ok for trunk?
Peter
gcc/
* config/rs6000/altivec.md (VParity): Use TARGET_VSX.
* config/rs6000/rs6000-cpus.def: Remove comment.
(ISA_2_7_MASKS_SERVER): Delete OPTION_MASK_VSX_TIMODE;
(POWERPC_
On 8/16/17 5:30 PM, Segher Boessenkool wrote:
> On Mon, Aug 14, 2017 at 04:28:25PM -0500, Peter Bergner wrote:
>> + mr %0,%L1; mr %L0,%1
>
>mr %0,%L1\;mr %L0,%1
So you want the ';' escaped and the space removed? Ok.
>> + [(set (match_operand:VSX_TI 0
On 8/16/17 5:56 PM, Peter Bergner wrote:
> On 8/16/17 5:30 PM, Segher Boessenkool wrote:
> I'll make the above changes and commit after another quick test cycle.
Testing the changes came up clean, so I committed it. Thanks.
Peter
simplification. Thanks!
Good catch. I doubled checked your suggested changes and agree with
all of them. I re-did bootstrap and regtesting of the changes and
they came up clean, so I committed it along with the extra simple
cleanup to FMOVE128_GPR that we discussed offline. Thanks.
Peter
uming testing passes?
Peter
gcc/
* config/rs6000/rs6000.c (rs6000_activate_target_options): New function.
(rs6000_set_current_function): Rewrite function to use it.
gcc/testsuite/
* gcc.target/powerpc/pr80210.c: New test.
Index: gcc/config/rs6000/rs6
On 8/18/17 6:27 PM, Segher Boessenkool wrote:
> On Thu, Aug 17, 2017 at 07:02:14PM -0500, Peter Bergner wrote:
>> This is also broken in GCC 7, GCC 6 and GCC 5. Ok for those after this
>> has been on trunk for a little while and assuming testing passes?
>
> Okay for t
On 8/18/17 9:19 PM, Peter Bergner wrote:
> On 8/18/17 6:27 PM, Segher Boessenkool wrote:
>> On Thu, Aug 17, 2017 at 07:02:14PM -0500, Peter Bergner wrote:
>>> This is also broken in GCC 7, GCC 6 and GCC 5. Ok for those after this
>>> has been on trunk for a little
rt redundant moves which then cannot be removed later).
>
> "0,r" might work, or "0,?r", or similar (alternatives have commas
> between them).
Right and alternatives that come first in the string are preferred
over alternatives that come later in the string, so in Segher's
example above, if both '0' and 'r' (or '?r') constraints are "ok",
then '0' is preferred over 'r' (or '?r').
Peter
both -m32 and -m64), so the first time through
rs6000_option_override_internal(),
we end up using processor_target_table[cpu_index].target_enable right from the
beginning.
The following patch fixes the problem I saw on Linux and bootstraps and regtests
with no regressions on LE and BE (run
(stmt)
&& !gimple_clobber_p (stmt))
return false;
}
return true;
}
> On Wed, 26 Apr 2017, Peter Bergner wrote:
>> One difference from the last patch is that I am no longer setting
>> default_label to NULL when we emit a decision tree. I noticed that
&
On 05/08/2017 12:44 PM, Richard Biener wrote:
On Wed, 26 Apr 2017, Peter Bergner wrote:
One difference from the last patch is that I am no longer setting
default_label to NULL when we emit a decision tree. I noticed that
the decision tree code seemed to generate slightly better code for
some
On 05/08/2017 01:20 PM, Peter Bergner wrote:
> That is what the previous patch did, but as I mention above,
> we generate slightly better code for some test cases (other
> tests seemed to generate the same code) if we don't attempt
> to handle the decision tree case. I'll
revisit this later if someone finds a test case that would benefit from
handling it for decision trees too.
This passes bootstrap and regtesting on powerpc64le-linux and x86_64-linux
with no regressions. Ok for trunk now?
Peter
gcc/
* tree-cfg.c (gimple_seq_unreachable_p): New function
On 5/11/17 3:49 PM, H.J. Lu wrote:
> This caused:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80714
This is already being tracked in https://gcc.gnu.org/PR80707
Peter
bootstrap issues they ran into.
Is this ok for trunk?
Peter
gcc/
PR middle-end/80707
* tree-cfg.c: Remove cfg edges of unreachable case statements.
gcc/testsuite/
* g++.dg/pr80707.C: New test.
Index: gcc/tree-cfg.c
On 5/12/17 11:51 AM, Richard Biener wrote:
> On May 12, 2017 6:46:29 PM GMT+02:00, Peter Bergner
> wrote:>> gcc/
>> PR middle-end/80707
>> * tree-cfg.c: Remove cfg edges of unreachable case statements.
>>
>> gcc/testsuite/
>> * g++.dg
point to unreachable blocks.
This bootstrapped and regtested with no regressions on both powerpc64le-linux
and x86_64-linux. Is this ok for trunk?
Peter
gcc/
PR middle-end/80775
* tree-cfg.c: Move deletion of unreachable case statements to after
the merging of consecutive
On 5/17/17 2:21 AM, Richard Biener wrote:
> On Tue, 16 May 2017, Peter Bergner wrote:
>> This bootstrapped and regtested with no regressions on both powerpc64le-linux
>> and x86_64-linux. Is this ok for trunk?
>
> Ok.
Committed as revision 248155. Thanks.
Peter
for many months
> now; I'll do one final test on powerpc64le-linux before committing.
>
> Do we want this before or after SPE is split off?
Isn't this a nop on SPE, since SPE's FP values live in GPRs?
If so, I would do whatever makes the job of committing the SPE
split easier.
Peter
strap and regtesting on powerpc64le-linux with no
regressions. Is this ok for trunk?
Peter
gcc/
PR middle-end/80823
* tree-cfg.c (group_case_labels_stmt): Delete increment of "i";
gcc/testsuite/
PR middle-end/80823
* gcc.dg/pr80823.c: New test.
Index:
On 5/24/17 2:15 AM, Richard Biener wrote:
> On May 23, 2017 7:46:59 PM GMT+02:00, Peter Bergner
> wrote:
>> gcc/
>> PR middle-end/80823
>> * tree-cfg.c (group_case_labels_stmt): Delete increment of "i";
>>
>> gcc/testsuite/
>>
Is it there and I'm just not seeing it?
Peter
7;m am tracking that down, but that will not make GCC 7.
Is this ok for trunk?
Peter
PR target/78516
* config/rs6000/spe.md (mov_si_e500_subreg0): Fix constraints.
Use the evmergelohi instruction.
(mov_si_e500_subreg4_2_le): Likewise.
(mov_sitf_e500_sub
On 1/18/17 8:04 PM, Segher Boessenkool wrote:
On Wed, Jan 18, 2017 at 02:38:30PM -0600, Peter Bergner wrote:
Is this ok for trunk?
This looks good, please apply. Thanks,
Thanks, committed as revision 244609.
Peter
both 32-bit and 64-bit). Ok for mainline?
Ok for the open release branches too?
Peter
gcc/
PR target/80246
* config/rs6000/dfp.md (dfp_dxex_): Update mode of operand 0.
(dfp_diex_): Update mode of operand 1.
* doc/extend.texi (dxex, dxexq): Document change to return
+/* { dg-final { scan-assembler-not "dctfixq" } } */
>
> If there is no "dctfix" there surely is no "dctfixq" either (i.e., your
> regexen aren't very tight).
Ahh, true. I suppose I could also just look for "drintn" too,
since that would catch both drintn. and drintnq., ok with that
change?
Peter
On 3/29/17 6:29 PM, Peter Bergner wrote:
> On 3/29/17 5:28 PM, Segher Boessenkool wrote:
>>> +/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
>>> +/* { dg-skip-if "" { powerpc*-*-*spe* } { "*" } { ""
this unless
you object.
/* { dg-final { scan-assembler-not "drintn\[q\]\." } } */
/* { dg-final { scan-assembler-not "dctfix\[q\]" } } */
/* { dg-final { scan-assembler-not "dcffix\[q\]" } } */
Peter
On 3/30/17 12:54 PM, Peter Bergner wrote:
> On 3/30/17 12:15 PM, Segher Boessenkool wrote:
>>>>> +/* { dg-final { scan-assembler-not "drintn\\." } } */
>>>>> +/* { dg-final { scan-assembler-not "drintnq\\." } } */
>>>>> +/*
ion __builtin_dxex requires the -mhard-dfp option
What configure options are you using? I would have expected this the
dg-require-effective-target to disable this test if you don't have
-mhard-dfp.
Peter
On 4/2/17 1:53 PM, Segher Boessenkool wrote:
> On Sun, Apr 02, 2017 at 09:48:36AM -0500, Peter Bergner wrote:
>> On 4/2/17 2:29 AM, Andreas Schwab wrote:
>>>> +/* { dg-require-effective-target dfp } */
>> [snip]
>>> FAIL: gcc.target/powerpc/pr80246.c (test
On 4/3/17 9:41 AM, Peter Bergner wrote:
> On 4/2/17 1:53 PM, Segher Boessenkool wrote:
>> I also have a fix for the dfp-builtin-1.c problem.
>
> You mean you have a patch to the regex to match both std/stw and ld/lwz?
I think we should also add:
/* { dg-require-effective-
_ok?
Seems like we should switch it to using hard_dfp now.
Peter
Index: dfp-builtin-1.c
===
--- dfp-builtin-1.c (revision 246648)
+++ dfp-builtin-1.c (working copy)
@@ -1,5 +1,5 @@
/* { dg-do compile { target { powerpc*-*-li
On 4/3/17 11:04 AM, Peter Bergner wrote:
> On 4/2/17 1:53 PM, Segher Boessenkool wrote:
>> I also have a fix for the dfp-builtin-1.c problem.
>
> Something like the following maybe? It seems to work for me.
> I think the hard_dfp predicate was added after the dfp-builtin-[12].c
On 4/3/17 12:01 PM, Peter Bergner wrote:
> On 4/3/17 11:04 AM, Peter Bergner wrote:
>> On 4/2/17 1:53 PM, Segher Boessenkool wrote:
>>> I also have a fix for the dfp-builtin-1.c problem.
>>
>> Something like the following maybe? It seems to work for me.
>> I th
and regtesting with no regressions on powerpc64-linux
and x86_64-linux. Ok for trunk now or trunk during stage1?
Peter
gcc/
* tree-cfg.c (gimple_unreachable_bb_p): New function.
(assert_unreachable_fallthru_edge_p): Use it.
* tree-cfg.h: Prototype it.
* stmt.c
etween
a switch statement written with no default case and one where
the default case was explicitly shown to be unreachable?
Maybe the default_label would be NULL for the unreachable
case and non-NULL in the other case? If so, we'd still need
my change that doesn't set default_label to fallback_label
and instead uses the new var gap_label.
Peter
xpansion so we can eliminate the range check. Thanks.
Peter
On 4/20/17 8:26 AM, Peter Bergner wrote:
> On 4/20/17 2:37 AM, Richard Biener wrote:
>> Ok, so I think we should ensure that we remove the regular cases
>> with unreachable destination, like in
>>
>> switch (i)
>> {
>> case 0:
>> __builtin_unrea
On 4/27/17 6:57 AM, Bernhard Reutner-Fischer wrote:
> On Wed, Apr 26, 2017 at 10:39:12PM -0500, Peter Bergner wrote:
>> +/* Returns true if the basic block BB has no successors and only contains
>> + a call to __builtin_unreachable (). */
>
> so
> return EDG
On 9/9/17 3:44 AM, Andreas Schwab wrote:
> On Sep 08 2017, Peter Bergner wrote:
>
>> The following patch fixes the problem I saw on Linux and bootstraps and
>> regtests
>> with no regressions on LE and BE (running testsuite in both 32-bit and 64-bit
>> modes).
in that we are not correctly saving and restoring the optab
values. The problem here is that rs6000_pragma_target_parse () did not
call rs6000_activate_target_options () which ends up resetting the
optabs values associated with the rs6000_isa_flags value.
This passed bootstrap and regtesting o
ad that already :-) )
Done.
> Looks great to me, please commit. But hold off until Monday please, it
> will interfere with testing otherwise.
Ok, committed now (Monday). I'd also like to back port this to the
GCC 7 and 6 release branches, where the earlier fix was also back
ported to. Ok there after a week or so of burn in on trunk?
Thanks.
Peter
Nicer still, we want the base address as the RA operand
and the offset as the RB operand, so like so:
li 9,7
lwbrx 10,4,9
lwbrx 9,5,9
On some processors, it matters performance wise.
Peter
arked as const/pure since we know
they have no side effects other than their return value?
Peter
On 2/28/17 12:49 PM, Peter Bergner wrote:
> On 2/25/17 2:40 AM, Prathamesh Kulkarni wrote:
>> The attached patch deletes calls to strdup, strndup if it's
>> return-value is unused,
>> and same for realloc if the first arg is NULL.
>
> Why limit ourselves to strd
our ICE.
The following patch passes bootstrap and regtesting on powerpc64le-linux.
Ok for the GCC 6 branch?
We don't hit this on trunk, because we're using LRA there, so I'm not
sure whether we want to add this there this late in the release cycle.
Peter
gcc/
PR target
merges. */
s/make sit/makes it/
Peter
On 9/9/16 5:51 PM, Jeff Law wrote:
On 08/30/2016 10:23 PM, Peter Bergner wrote:
gcc/
PR rtl-optimization/77289
* lra-constraints.c (get_final_hard_regno): Add support for non hard
register numbers. Remove support for subregs.
(get_hard_regno): Use SUBREG_P. Don't
does pass.
Peter
ing missed even if we have it documented.
We don't want new ports to find out they need to enable LRA during
their patch submission, since that entails a huge amount of retesting.
It should be LRA from day 1 for them.
Peter
patch for the doc update (I hope the wording is strong enough).
Maybe s/New ports should use LRA/New ports must use LRA/ ?
+ New ports should use LRA, and existing ports are encouraged to convert.
^^
extra space
Peter
Now that we have a GCC 7 changes.html file, shouldn't we make it easy to find?
Peter
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.1027
diff -u -r1.1027 index.html
--- index.html 3
On 10/25/16 12:17 PM, Gerald Pfeifer wrote:
> On Tue, 25 Oct 2016, Peter Bergner wrote:
>> Now that we have a GCC 7 changes.html file, shouldn't we make it
>> easy to find?
>
> Good point, thanks.
>
> Perhaps add a disclaimer at the top of changes.html that thi
On 10/25/16 12:50 PM, Peter Bergner wrote:
> On 10/25/16 12:17 PM, Gerald Pfeifer wrote:
>> Perhaps add a disclaimer at the top of changes.html that this
>> is still work in progress as part of that commit?
>
> Do you mean like the following? If so, we'd have to rem
On 10/26/16 1:10 PM, Gerald Pfeifer wrote:
On Tue, 25 Oct 2016, Peter Bergner wrote:
Perhaps add a disclaimer at the top of changes.html that this
is still work in progress as part of that commit?
Do you mean like the following? If so, we'd have to remember to
remove the last hunk when
irect moves for TDmode values.
This passed bootstrap and regtesting with no regressions. Ok for trunk?
This is also broken on the FSF 6 branch, so is this ok there too after
bootstrap and regtesting there?
Peter
gcc/
PR target/71698
* config/rs6000/rs6
On 6/30/16 6:21 PM, Segher Boessenkool wrote:
On Thu, Jun 30, 2016 at 05:55:04PM -0500, Peter Bergner wrote:
We currently don't allow TDmode values to use direct moves, since they
live in register pairs and the most significant word is always in the
even-numbered register which does not
On 6/27/16 8:30 PM, Peter Bergner wrote:
On 6/27/16 3:21 PM, Segher Boessenkool wrote:
On Sat, Jun 25, 2016 at 07:14:01PM -0500, Peter Bergner wrote:
Okay for trunk, okay for 6 later. One comment:
+ if (VECTOR_MODE_P (mode)
+ && !mode_supports_vsx_dform_quad (mode))
+retu
regtested with no regessions. Ok for trunk?
This also affects the FSF 6 branch, ok there too, assuming bootstrap and
regtesting complete cleanly?
Peter
gcc/
* config/rs6000/rs6000.c (rs6000_option_override_internal): Disable
-mpower9-dform-vector when disabling -mpower9-vector.
gcc
On 7/6/16 12:53 PM, David Edelsohn wrote:
On Tue, Jul 5, 2016 at 10:26 PM, Peter Bergner wrote:
The following patch fixes a bug where we do not disable POWER9 vector dform
addressing when we compile for POWER9 but without VSX support. This manifested
itself with us trying to use dform
On 7/6/16 2:19 PM, Michael Meissner wrote:
On Tue, Jul 05, 2016 at 09:26:50PM -0500, Peter Bergner wrote:
- rs6000_isa_flags &= ~OPTION_MASK_P9_VECTOR;
+ rs6000_isa_flags &= ~(OPTION_MASK_P9_VECTOR
+ | OPTION_MASK_P9_DFORM_VECTOR);
}
Note, thi
On 7/6/16 6:29 PM, Michael Meissner wrote:
On Wed, Jul 06, 2016 at 05:01:38PM -0500, Peter Bergner wrote:
I had thought about adding the dform scalar flag, but it was already
correctly disabled and I wasn't sure whether we could have the p9
dform scalar without the vector part. Probabl
On 7/6/16 12:53 PM, David Edelsohn wrote:
> On Tue, Jul 5, 2016 at 10:26 PM, Peter Bergner wrote:
>> The following patch fixes a bug where we do not disable POWER9 vector dform
>> addressing when we compile for POWER9 but without VSX support. This
>> manifested
>> i
en they're
not legal for these patterns.
As I said in my previous note, I wasn't able to actually generate the
altivec pattern (I haven't tried the vsx reg+reg patterns), but if we
could, I assume we'll still have the same issue, will we not?
Peter
501 - 600 of 1978 matches
Mail list logo
