Hi! Ping, please. :-)
Bill
On 9/29/21 3:38 PM, Bill Schmidt wrote:
> Hi Segher,
>
> Might as well ping this before I go on vacation. :-) I think we're up to
> 06/18:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578604.html
>
> Thanks!!
>
> Bill
Hi! Ping, please. :)
Bill
On 9/24/21 10:20 AM, Bill Schmidt wrote:
> Hi!
>
> This fixes a bug reported in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985.
>
> The vec_cpsgn built-in function API differs in argument order from the
> copysign3 convention. Currently that pattern is
Hi Segher,
Might as well ping this before I go on vacation. :-) I think we're up to
06/18:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578604.html
Thanks!!
Bill
Hi Kewen,
On 9/28/21 9:34 PM, Kewen.Lin wrote:
> Hi Bill,
>
> Thanks for your prompt comments!
>
> on 2021/9/29 上午3:24, Bill Schmidt wrote:
>> Hi Kewen,
>>
>> Although I agree that what we do now is tragically bad (and will be fixed in
>> the builtin rewrite), this seems a little too cavalier to
Hi Kewen,
Although I agree that what we do now is tragically bad (and will be fixed in
the builtin rewrite), this seems a little too cavalier to remove all checking
during initialization without adding any checking somewhere else. :-) We still
need to check for invalid usage when the builtin
Hi!
This fixes a bug reported in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985.
The vec_cpsgn built-in function API differs in argument order from the
copysign3 convention. Currently that pattern is incorrctly used to
implement vec_cpsgn. Fix that while leaving the existing pattern in
Hi Segher,
Thanks for the review! This is what I committed.
2021-09-23 Bill Schmidt
gcc/
PR target/102024
* config/rs6000/rs6000-call.c (rs6000_aggregate_candidate): Detect
zero-width bit fields and return indicator.
(rs6000_discover_homogeneous_aggregate):
Hi Jakub,
On 9/22/21 11:33 AM, Jakub Jelinek wrote:
On Wed, Sep 22, 2021 at 05:02:15PM +0200, Jakub Jelinek via Gcc-patches wrote:
@@ -6298,7 +6298,8 @@ rs6000_aggregate_candidate (const_tree type, machine_mode
*modep,
return -1;
count = rs6000_aggregate_candidate (TREE_TYPE
On 9/22/21 9:35 AM, will schmidt wrote:
On Tue, 2021-09-21 at 17:35 -0500, Bill Schmidt wrote:
Hi!
Previously zero-width bit fields were removed from structs, so that otherwise
homogeneous aggregates were treated as such and passed in FPRs and VSRs.
This was incorrect behavior per the ELFv2
On Tue, 2021-09-21 at 17:35 -0500, Bill Schmidt wrote:
> Hi!
>
> Previously zero-width bit fields were removed from structs, so that otherwise
> homogeneous aggregates were treated as such and passed in FPRs and VSRs.
> This was incorrect behavior per the ELFv2 ABI. Now that these fields are no
Hi!
Previously zero-width bit fields were removed from structs, so that otherwise
homogeneous aggregates were treated as such and passed in FPRs and VSRs.
This was incorrect behavior per the ELFv2 ABI. Now that these fields are no
longer being removed, we generate the correct parameter passing
Hi Kewen,
On 9/15/21 8:14 PM, Kewen.Lin wrote:
Hi,
This patch follows the discussion here[1], where Segher pointed
out the existing way to guard the extra penalized cost for
strided/elementwise loads with a magic bound doesn't scale.
The way with nunits * stmt_cost can get one much
Hi Kewen,
On 9/15/21 3:52 AM, Kewen.Lin wrote:
Hi,
This patch follows the discussion here[1], where Segher suggested
parameterizing those exact magic constants for density heuristics,
to make it easier to tweak if need.
Since these heuristics are quite internal, I make these parameters
as
Thanks! I'll remove the elses in the committed patch, along with a TODO
comment for the additional factoring opportunity for when I get to that
stage.
Thanks for all the reviews!
Bill
On 9/16/21 6:38 PM, Segher Boessenkool wrote:
Hi!
On Wed, Sep 01, 2021 at 11:13:40AM -0500, Bill Schmidt
Thank you, Tobias! This looks good to me and doesn't break
host=target=build bootstrap. I appreciate the patch very much. (I
can't approve it, so please wait for Segher/David to weigh in.)
Bill
On 9/16/21 4:07 AM, Tobias Burnus wrote:
As mentioned in https://gcc.gnu.org/PR102353 and in
Hi Will,
On 9/13/21 1:42 PM, will schmidt wrote:
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
This is another patch that looks bigger than it really is. Because we
have a new namespace for the builtins, allowing us to have both the old
and new builtin infrastructure
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> This patch just duplicates a couple of functions and adjusts them to use the
> new builtin names. There's no logical change otherwise.
>
> 2021-08-31 Bill Schmidt
>
> gcc/
> * config/rs
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> Peter Bergner recently added two new builtins __builtin_vsx_lxvp and
> __builtin_vsx_stxvp. These happened to break a pattern in MMA builtins that
> I had been using to automate gimple folding of MMA builtins. P
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> This is another patch that looks bigger than it really is. Because we
> have a new namespace for the builtins, allowing us to have both the old
> and new builtin infrastructure supported at once, we need
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> I over-restricted use of __builtin_mffsl, since I was unaware that it
> automatically uses mffs when mffsl is not available. Paul Clarke
> pointed
> this out in discussion of his SSE 4.1 compatibility patches.
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
Hi,
Just a couple cosmetic nits noted below, the majority if which is also in
the original code this is based on.
THanks
-Will
> Although this patch looks quite large, the changes are fairly minimal.
>
Ping.
Message-Id:
Thanks!
Bill
On 9/1/21 11:13 AM, Bill Schmidt via Gcc-patches wrote:
Hi!
Original patch series here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568840.html
V2 patch series here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572231.html
V3 patch series
Hi Kewen,
I'll leave the continued review of the back-end parts of this to Segher,
but I do have one long-term comment. The rs6000_builtin_info[code].mask
field that you're relying on is going away as part of the built-in
function rewrite. There will be a "bifattrs" field that replaces this
Hi Haochen,
On 9/8/21 1:42 AM, HAO CHEN GUI wrote:
Hi,
The patch optimized for vec_reve builtin on rs6000. For V2DI and
V2DF, it is implemented by xxswapd on all targets. For V16QI, V8HI, V4SI
and V4SF, it is implemented by quadword byte reverse plus halfword/word
byte reverse when
Hi Peter,
This patch looks fine to me. The approach to avoiding incorrect
optimization is reasonable. Maintainers?
Thanks for the patch!
Bill
On 8/27/21 2:58 PM, Peter Bergner via Gcc-patches wrote:
Fwprop will happily optimize two xxsetaccz instructions into one xxsetaccz
by propagating
On 9/10/21 12:45 AM, HAO CHEN GUI wrote:
Bill,
Thanks so much for your advice.
I refined the patch and passed the bootstrap and regression test.
Just one thing, the test case becomes unsupported on P9 if I set "{
dg-require-effective-target power10_ok }". I just want the test case to
On 9/9/21 12:19 PM, Bill Schmidt wrote:
On 9/9/21 11:11 AM, Segher Boessenkool wrote:
Hi!
On Wed, Sep 08, 2021 at 02:57:14PM +0800, Kewen.Lin wrote:
+ /* If we have strided or elementwise loads into a vector, it's
+possible to be bounded by latency and execution resources for
+
On 9/9/21 11:11 AM, Segher Boessenkool wrote:
Hi!
On Wed, Sep 08, 2021 at 02:57:14PM +0800, Kewen.Lin wrote:
+ /* If we have strided or elementwise loads into a vector, it's
+possible to be bounded by latency and execution resources for
+many scalar loads. Try to account
Hi Kewen,
Sorry that we lost track of this patch! The heuristic approach looks
good. It is limited in scope and won't kick in often, and the case
you're trying to account for is important.
At the time you submitted this, I think reliable P10 testing wasn't
possible. Now that it is, could
Hi Xionghu,
This looks okay to me. Recommend maintainers approve.
Thanks!
Bill
On 9/2/21 9:31 PM, Xionghu Luo wrote:
Resend the patch that addressed Will's comments.
fmod/fmodf and remainder/remainderf could be expanded instead of library
call when fast-math build, which is much faster.
2021-08-19 Bill Schmidt
gcc/
* config/rs6000/rs6000-builtin-new.def (VEC_INIT_V16QI): Use
escape-newline support.
(VEC_INIT_V4SI): Likewise.
(VEC_INIT_V8HI): Likewise.
(PACK_V1TI): Likewise.
(DIVDEU): Likewise.
2021-07-19 Bill Schmidt
gcc/testsuite/
* gcc.target/powerpc/bfp/scalar-extract-exp-2.c: Adjust.
* gcc.target/powerpc/bfp/scalar-extract-sig-2.c: Adjust.
* gcc.target/powerpc/bfp/scalar-insert-exp-2.c: Adjust.
* gcc.target/powerpc/bfp/scalar-insert-exp-5.c:
2021-03-05 Bill Schmidt
gcc/
* config/rs6000/rs6000-gen-builtins.c (write_init_file):
Initialize new_builtins_are_live to 1.
---
gcc/config/rs6000/rs6000-gen-builtins.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/rs6000/rs6000-gen-builtins.c
2021-07-28 Bill Schmidt
gcc/
* config/rs6000/altivec.h: Delete a number of #defines that are
now superfluous. Alphabetize. Include rs6000-vecdefines.h.
Include some synonyms.
---
gcc/config/rs6000/altivec.h | 519 +++-
1 file changed,
2021-07-28 Bill Schmidt
gcc/
* config/rs6000/rs6000-call.c (rs6000_debug_type): New function.
(def_builtin): Change debug formatting for easier parsing and
include more information.
(rs6000_init_builtins): Add dump of autogenerated builtins.
There are a few leftover places where we use the old rs6000_builtins_decl
array, but we need to use rs6000_builtins_decl_x instead when the new
builtins infrastructure is in play.
2021-07-28 Bill Schmidt
gcc/
* config/rs6000/rs6000.c (rs6000_builtin_reciprocal): Use
Create a new version of this function that uses the new infrastructure,
and particularly checks for supported builtins the new way.
2021-08-31 Bill Schmidt
gcc/
* config/rs6000/rs6000-call.c (rs6000_new_builtin_decl): New
function.
(rs6000_builtin_decl): Call it.
---
Provide replacements for htm_spr_num and htm_expand_builtin. No logic
changes are intended here, as usual. Much code was factored out into
rs6000_expand_new_builtin, so the new version of htm_expand_builtin is
a little tidier.
Also implement the support for the "endian" and "32bit" attributes,
Replace mma_expand_builtin. There are no significant logic changes,
just adjustments to use the new infrastructure and clean up formatting.
2021-09-01 Bill Schmidt
gcc/
* config/rs6000/rs6000-call.c (new_mma_expand_builtin):
Implement.
---
gcc/config/rs6000/rs6000-call.c |
Consolidate into elemrev_icode some logic that is scattered throughout
the old altivec_expand_builtin. Also replace functions for handling
special load and store built-ins:
= ldv_expand_builtin replaces altivec_expand_lv_builtin
= lxvrse_expand_builtin and lxvrze_expand_builtin replace
Implement the replacement for cpu_expand_builtin. There are no logic
changes here, just changes to use the new built-in function names and
clean up some formatting.
2021-09-01 Bill Schmidt
gcc/
* config/rs6000/rs6000-call.c (new_cpu_expand_builtin):
Implement.
---
Implement rs6000_invalid_new_builtin, which issues the appropriate error
message when a builtin is used when it is not enabled. Also implement
rs6000_expand_ldst_mask, which just factors out the code that handles
ALTIVEC_BUILTIN_MASK_FOR_LOAD in the old rs6000_expand_builtin. Finally,
ensure the
This patch and the subsequent five patches form the meat of the improvements
for this patch series. We develop a replacement for rs6000_expand_builtin
and its supporting functions, which are inefficient and difficult to
maintain. This patch implements rs6000_expand_new_builtin, and creates
stubs
This patch just duplicates a couple of functions and adjusts them to use the
new builtin names. There's no logical change otherwise.
2021-08-31 Bill Schmidt
gcc/
* config/rs6000/rs6000.c (rs6000-builtins.h): New include.
(rs6000_new_builtin_vectorized_function): New function.
This is another patch that looks bigger than it really is. Because we
have a new namespace for the builtins, allowing us to have both the old
and new builtin infrastructure supported at once, we need versions of
these functions that use the new builtin namespace. Otherwise the code is
unchanged.
Peter Bergner recently added two new builtins __builtin_vsx_lxvp and
__builtin_vsx_stxvp. These happened to break a pattern in MMA builtins that
I had been using to automate gimple folding of MMA builtins. Previously,
every MMA function that could be folded had an associated internal function
I over-restricted use of __builtin_mffsl, since I was unaware that it
automatically uses mffs when mffsl is not available. Paul Clarke pointed
this out in discussion of his SSE 4.1 compatibility patches.
2021-08-31 Bill Schmidt
gcc/
* config/rs6000/rs6000-call.c (__builtin_mffsl):
Hi!
Original patch series here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568840.html
V2 patch series here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572231.html
V3 patch series here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573020.html
V4 patch series here:
Although this patch looks quite large, the changes are fairly minimal.
Most of it is duplicating the large function that does the overload
resolution using the automatically generated data structures instead of
the old hand-generated ones. This doesn't make the patch terribly easy to
review,
Hi Segher,
On 8/27/21 6:07 PM, Segher Boessenkool wrote:
Hi!
On Thu, Jul 29, 2021 at 08:31:06AM -0500, Bill Schmidt wrote:
Although this patch looks quite large, the changes are fairly minimal.
Most of it is duplicating the large function that does the overload
resolution using the
Hi Paul,
On 8/30/21 4:16 PM, Paul A. Clarke wrote:
On Fri, Aug 27, 2021 at 08:44:43AM -0500, Bill Schmidt via Gcc-patches wrote:
On 8/23/21 2:03 PM, Paul A. Clarke wrote:
+ __fpscr_save.__fr = __builtin_mffsl ();
As pointed out in the v1 review, __builtin_mffsl is enabled (or supposed
Hi Mike,
Thanks for this clean-up!
On 8/25/21 5:09 PM, Michael Meissner wrote:
From 327273dfeec5c000f3c33ca7b88ee0097fd33586 Mon Sep 17 00:00:00 2001
From: Michael Meissner
Date: Wed, 25 Aug 2021 00:31:35 -0400
Subject: [PATCH] Fix float128-call.c test for power8 IEEE 128 and power10.
I
Hi Paul,
Thanks for the changes! This looks fine to me, recommend approval.
Thanks,
Bill
On 8/23/21 2:03 PM, Paul A. Clarke wrote:
Some compatibility implementations of x86 intrinsics include
Power intrinsics which require POWER8. Guard them.
emmintrin.h:
- _mm_cmpord_pd: Remove code which
Hi Paul,
On 8/23/21 2:03 PM, Paul A. Clarke wrote:
Function signatures and decorations match gcc/config/i386/smmintrin.h.
Also, copy tests for:
- _mm_cmpeq_epi64
- _mm_mullo_epi32, _mm_mul_epi32
- _mm_packus_epi32
- _mm_cmpgt_epi64 (SSE4.2)
from gcc/testsuite/gcc.target/i386.
2021-08-23
This looks fine, recommend approval.
Thanks!
Bill
On 8/23/21 2:03 PM, Paul A. Clarke wrote:
Function signatures and decorations match gcc/config/i386/smmintrin.h.
Also, copy tests for:
- _mm_cvtepi8_epi16, _mm_cvtepi8_epi32, _mm_cvtepi8_epi64
- _mm_cvtepi16_epi32, _mm_cvtepi16_epi64
-
This looks fine, recommend approval.
Thanks!
Bill
On 8/23/21 2:03 PM, Paul A. Clarke wrote:
Copy some simple redirections from i386 , for:
- _mm_test_all_zeros
- _mm_test_all_ones
- _mm_test_mix_ones_zeros
2021-08-20 Paul A. Clarke
gcc
* config/rs6000/smmintrin.h
Hi Paul,
This looks fine to me, recommend approval.
Thanks,
Bill
On 8/23/21 2:03 PM, Paul A. Clarke wrote:
Function signatures and decorations match gcc/config/i386/smmintrin.h.
Also, copy tests for _mm_min_epi8, _mm_min_epu16, _mm_min_epi32,
_mm_min_epu32, _mm_max_epi8, _mm_max_epu16,
On 8/27/21 8:44 AM, Bill Schmidt wrote:
Again, please specify where the patch was tested and whether this is for
trunk, backports, etc. Thanks! (I know you aren't asking for
backports, but in general please get in the habit of this.)
Sorry, I see that you did this in the cover letter.
Hi Paul,
On 8/23/21 2:03 PM, Paul A. Clarke wrote:
Suppress exceptions (when specified), by saving, manipulating, and
restoring the FPSCR. Similarly, save, set, and restore the floating-point
rounding mode when required.
No attempt is made to optimize writing the FPSCR (by checking if the new
Hi Segher,
On 8/26/21 6:15 PM, Segher Boessenkool wrote:
Hi!
On Thu, Jul 29, 2021 at 08:31:02AM -0500, Bill Schmidt wrote:
* config/rs6000/rs6000-call.c (rs6000-builtins.h): New #include.
(rs6000_init_builtins): Call rs6000_autoinit_builtins; skip the old
On Wed, 2021-08-25 at 15:46 -0400, Michael Meissner wrote:
> Generate XXSPLTIDP on power10.
>
> This patch implements XXSPLTIDP support for SF and DF scalar constants and
> V2DF
> vector constants. The XXSPLTIDP instruction is given a 32-bit immediate that
> is converted to a vector of two
Hi Segher,
On 8/25/21 6:27 PM, Segher Boessenkool wrote:
On Thu, Jul 29, 2021 at 08:31:01AM -0500, Bill Schmidt wrote:
* config/rs6000/rs6000-overload.def: Add remaining overloads.
+; TODO: Note that the entry for VEC_ADDE currently gets ignored in
+;
Hi Haochen,
Thanks for the updates! This looks good to me; please await Segher's
response.
Bill
On 8/25/21 2:06 AM, HAO CHEN GUI wrote:
Hi,
I refined the patch according to Bill's advice. I pasted the
ChangeLog and diff file here. If it doesn't work, please let me know.
Thanks.
Hi Hao Chen,
On 8/24/21 3:52 AM, HAO CHEN GUI wrote:
Hi
The patch disables gimple fold for float or double vec_min/max
builtin when fast-math is not set. Two test cases are added to verify
the patch.
The attachments are the patch diff and change log file.
Bootstrapped and
Hi Kewen,
Sorry this sat in my queue for so long. It looks like you addressed all
of our concerns, so LGTM -- recommend maintainers approve.
Thanks!
Bill
On 8/12/21 9:34 PM, Kewen.Lin wrote:
Hi Segher,
Thanks for the review!
on 2021/8/12 下午11:10, Segher Boessenkool wrote:
Hi!
On Wed,
On 8/24/21 10:38 AM, Segher Boessenkool wrote:
Hi!
On Tue, Aug 24, 2021 at 09:20:09AM -0500, Bill Schmidt wrote:
On 8/23/21 4:40 PM, Segher Boessenkool wrote:
On Thu, Jul 29, 2021 at 08:30:55AM -0500, Bill Schmidt wrote:
+; These things need some review to see whether they really require
+;
On 8/23/21 5:15 PM, Segher Boessenkool wrote:
On Thu, Jul 29, 2021 at 08:30:56AM -0500, Bill Schmidt wrote:
* config/rs6000/rs6000-call.c (rs6000_init_builtins): Initialize
various pointer type nodes.
* config/rs6000/rs6000.h (rs6000_builtin_type_index): Add enum
On 8/23/21 4:40 PM, Segher Boessenkool wrote:
On Thu, Jul 29, 2021 at 08:30:55AM -0500, Bill Schmidt wrote:
2021-06-15 Bill Schmidt
* config/rs6000/rs6000-builtin-new.def: Add power9-vector, power9,
and power9-64 stanzas.
+; These things need some review to see whether they
Hi,
My recent commit broke bootstrap for AIX because I was calling asprintf
without pulling it in from libiberty.h. Unfortunately, there is a name
collision between libiberty.h and string.h that I don't immediately know
how to resolve, so rather than fight it I've just reverted to using
Hi,
I totally biffed the previous version of this patch, as it was built
against an experimental tree instead of trunk. Trying again...
Although safe_inc_pos avoids buffer overruns in rs6000-gen-builtins.c,
there are some other routines where we fail to detect the possibility.
Clean those up!
Hi Mike,
On 8/12/21 11:20 PM, Michael Meissner wrote:
Move xx* builtins to vsx.md.
I originally posted this patch in May. It needed a slight tune up as the
souces have changed, so I'm reposting it now.
I noticed that the xx built-in functions (xxspltiw, xxspltidp, xxsplti32dx,
xxeval,
Hi Paul,
On 8/9/21 3:23 PM, Paul A. Clarke via Gcc-patches wrote:
Some compatibility implementations of x86 intrinsics include
Power intrinsics which require POWER8. Guard them.
emmintrin.h:
- _mm_cmpord_pd: Remove code which was ostensibly for pre-POWER8,
but which indeed depended on
Hi Paul,
On 8/9/21 3:23 PM, Paul A. Clarke via Gcc-patches wrote:
Also, copy tests for:
- _mm_cmpeq_epi64, _mm_cmpgt_epi64
- _mm_mullo_epi32, _mm_mul_epi32
- _mm_packus_epi32
from gcc/testsuite/gcc.target/i386.
Testing, backports, etc.
This patch LGTM with the usual comment about
Hi Paul,
On 8/9/21 3:23 PM, Paul A. Clarke via Gcc-patches wrote:
Also, copy tests for:
- _mm_cvtepi8_epi16, _mm_cvtepi8_epi32, _mm_cvtepi8_epi64
- _mm_cvtepi16_epi32, _mm_cvtepi16_epi64
- _mm_cvtepi32_epi64,
- _mm_cvtepu8_epi16, _mm_cvtepu8_epi32, _mm_cvtepu8_epi64
- _mm_cvtepu16_epi32,
Hi Paul,
On 8/9/21 3:23 PM, Paul A. Clarke via Gcc-patches wrote:
Copy some simple redirections from i386 , for:
- _mm_test_all_zeros
- _mm_test_all_ones
- _mm_test_mix_ones_zeros
Testing, backports, etc.
Simple is good! LGTM.
Bill
2021-08-09 Paul A. Clarke
gcc
*
Hi Paul,
On 8/9/21 3:23 PM, Paul A. Clarke via Gcc-patches wrote:
Also, copy tests for _mm_min_epi8, _mm_min_epu16, _mm_min_epi32,
_mm_min_epu32, _mm_max_epi8, _mm_max_epu16, _mm_max_epi32, _mm_max_epu32
from gcc/testsuite/gcc.target/i386.
sse4_1-pmaxsb.c and sse4_1-pminsb.c were modified from
Hi, Paul!
On 8/9/21 3:23 PM, Paul A. Clarke via Gcc-patches wrote:
Suppress exceptions (when specified), by saving, manipulating, and
restoring the FPSCR. Similarly, save, set, and restore the floating-point
rounding mode when required.
No attempt is made to optimize writing the FPSCR (by
Hi Peter,
On 8/13/21 12:01 PM, Peter Bergner wrote:
On 8/12/21 1:20 PM, David Edelsohn wrote:
On Tue, Aug 10, 2021 at 7:37 PM Peter Bergner wrote:
gcc/
PR target/101849
* config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin): Cast
pointer to __vector_pair *.
Hi,
On 8/12/21 3:43 PM, Bill Schmidt via Gcc-patches wrote:
Per discussion with Martin, I'm also changing the post-increment to
pre-increment in safe_inc_pos. That's what I'm regstrapping at the moment.
Thanks,
Bill
On 8/12/21 3:28 PM, Bill Schmidt via Gcc-patches wrote:
Although
Per discussion with Martin, I'm also changing the post-increment to
pre-increment in safe_inc_pos. That's what I'm regstrapping at the moment.
Thanks,
Bill
On 8/12/21 3:28 PM, Bill Schmidt via Gcc-patches wrote:
Although safe_inc_pos avoids buffer overruns in rs6000-gen-builtins.c
Although safe_inc_pos avoids buffer overruns in rs6000-gen-builtins.c,
there are some other routines where we fail to detect the possibility.
Clean those up!
Regstrap in progress on powerpc64le-linux-gnu. OK for trunk if that
passes?
Thanks,
Bill
2021-08-12 Bill Schmidt
gcc/
*
Hi Segher,
On 8/3/21 7:34 PM, Segher Boessenkool wrote:
Whoops, I forgot some stuff:
On Tue, Jul 27, 2021 at 04:06:49PM -0500, will schmidt wrote:
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
static rtx
ldv_expand_builtin (rtx target, insn_code icode, rtx *op
On 8/10/21 11:02 AM, Bill Schmidt wrote:
Hm, is this code ever executed? How does this not result in assignment
through null pointers?
It would be good to figure out whether this code is reachable at all,
and just yank it out if not. Otherwise we need a test case that hits it.
I seem to
On 8/11/21 9:10 PM, Kewen.Lin wrote:
Hi Bill,
Thanks for your prompt review!
on 2021/8/12 上午12:34, Bill Schmidt wrote:
Hi Kewen,
FWIW, it's easier on reviewers if you include the patch inline instead of as an
attachment.
On 8/11/21 1:56 AM, Kewen.Lin wrote:
Hi,
This patch is to add the
Hi Peter,
LGTM. Still needs maintainer review, of course. :)
Bill
On 8/10/21 6:37 PM, Peter Bergner wrote:
PR101849 shows we ICE on a test case when we pass a non __vector_pair *
pointer to the __builtin_vsx_lxvp and __builtin_vsx_stxvp built-ins
that is cast to __vector_pair *. The problem
Hi Kewen,
FWIW, it's easier on reviewers if you include the patch inline instead
of as an attachment.
On 8/11/21 1:56 AM, Kewen.Lin wrote:
Hi,
This patch is to add the support to make vectorizer able to
vectorize scalar version of some built-in functions with its
corresponding vector
Hi Kewen,
On 8/11/21 12:44 AM, Kewen.Lin wrote:
Hi,
This patch is to make prototypes of some Power10 built-in
functions consistent with what's in the documentation, as
well as the vector version. Otherwise, useless conversions
can be generated in gimple IR, and the vectorized versions
will
Hi Segher,
On 8/10/21 12:34 PM, Segher Boessenkool wrote:
On Tue, Aug 10, 2021 at 11:17:05AM -0500, will schmidt wrote:
On Thu, 2021-07-29 at 08:30 -0500, Bill Schmidt wrote:
+; This will break for long double == _Float128. libgcc history.
+ const long double __builtin_pack_longdouble
Hi Segher,
On 8/10/21 1:38 PM, Segher Boessenkool wrote:
On Thu, Jul 29, 2021 at 08:30:52AM -0500, Bill Schmidt wrote:
* config/rs6000/rs6000-builtin-new.def: Add always, power5, and
power6 stanzas.
+ unsigned long __builtin_ppc_mftb ();
+MFTB rs6000_mftb_di {32bit}
I'm
On Thu, 2021-07-29 at 08:30 -0500, Bill Schmidt wrote:
> 2021-04-02 Bill Schmidt
>
Hi,
> gcc/
> * config/rs6000/rs6000-builtin-new.def: Add power7 and power7-64
> stanzas.
ok
> ---
> gcc/config/rs6000/rs6000-builtin-new.def | 39
> 1 file changed, 39
On Thu, 2021-07-29 at 08:30 -0500, Bill Schmidt wrote:
> 2021-06-07 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000-builtin-new.def: Add always, power5, and
> power6 stanzas.
> ---
> gcc/config/rs6000/rs6000-builtin-new.def | 72
> 1 file changed, 72
On Thu, 2021-07-29 at 08:30 -0500, Bill Schmidt wrote:
> 2021-06-07 Bill Schmidt
>
Hi,
> gcc/
> * config/rs6000/rs6000-builtin-new.def: Add vsx stanza.
> ---
> gcc/config/rs6000/rs6000-builtin-new.def | 857 +++
> 1 file changed, 857 insertions(+)
>
ok
> diff
On 8/10/21 8:40 AM, Segher Boessenkool wrote:
On Tue, Aug 10, 2021 at 08:02:24AM -0500, Bill Schmidt wrote:
The whole point is that this data type is only used for interfaces, as
shown in the example code. Nobody wants to define const void as
anything. The const serves only as a contract
On 8/10/21 7:48 AM, Segher Boessenkool wrote:
On Tue, Aug 10, 2021 at 07:17:54AM -0500, Bill Schmidt wrote:
On 8/9/21 6:44 PM, Segher Boessenkool wrote:
This is not a documented GCC extension either, and it might even
conflict with the existing void * extension (allowing arithmetic on it,
by
On 8/9/21 6:44 PM, Segher Boessenkool wrote:
This is not a documented GCC extension either, and it might even
conflict with the existing void * extension (allowing arithmetic on it,
by defining sizeof(void)). In either case it is not currently defined.
I'm not sure how you get to this,
Hi Segher,
+ pcvoid_type_node
+= build_pointer_type (build_qualified_type (void_type_node,
+ TYPE_QUAL_CONST));
A const void? Interesting. You are building a pointer to a const void
here, not a const pointer to void. Is that what you wanted?
Hi...
On 8/8/21 3:27 PM, Segher Boessenkool wrote:
Hi!
On Sun, Aug 08, 2021 at 11:53:38AM -0500, Bill Schmidt wrote:
On 8/6/21 7:01 PM, Segher Boessenkool wrote:
On Thu, Jul 29, 2021 at 08:30:50AM -0500, Bill Schmidt wrote:
+ const vsc __builtin_altivec_abss_v16qi (vsc);
+ABSS_V16QI
Hi Segher,
On 8/6/21 7:01 PM, Segher Boessenkool wrote:
Hi!
On Thu, Jul 29, 2021 at 08:30:50AM -0500, Bill Schmidt wrote:
+ const vsc __builtin_altivec_abss_v16qi (vsc);
+ABSS_V16QI altivec_abss_v16qi {}
+
+ const vsi __builtin_altivec_abss_v4si (vsi);
+ABSS_V4SI altivec_abss_v4si
Hi Mike,
FWIW, looks fine to me, if tests are all passing now.
Bill
On 8/5/21 9:44 PM, Michael Meissner wrote:
[PATCH] Fix typo in fold-vec-load-builtin_vec_xl-* tests.
When I checked in the fix for running tests on power10 systems with
power10 code generation, I had a typo in the
Hi Kewen,
On 8/4/21 9:06 PM, Kewen.Lin wrote:
Hi,
The existing vec_unpacku_{hi,lo} supports emulated unsigned
unpacking for short and char but misses the support for int.
This patch adds the support for vec_unpacku_{hi,lo}_v4si.
Meanwhile, the current implementation uses vector permutation
201 - 300 of 902 matches
Mail list logo
