On 1/25/21 10:23 AM, Segher Boessenkool wrote:
Hi!
On Thu, Jan 21, 2021 at 05:49:14PM -0600, will schmidt wrote:
Noted as part of the work-in-progress builtins rewrite, the
__builtin_dfp_dtstsfi_*_{dd,td} builtins are redundant, and are thusly
being marked as deprecated. They will be remove
Hi Will,
On 7/29/21 7:42 AM, Bill Schmidt wrote:
On 7/28/21 4:21 PM, will schmidt wrote:
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
+/* Vector compares; EQ, NE, GE, GT, LE. */
+case RS6000_BIF_VCMPEQUB:
+case RS6000_BIF_VCMPEQUH:
+case
Hi Pat,
Good stuff! Comments below.
On 8/2/21 3:19 PM, Pat Haugen via Gcc-patches wrote:
Enable store fusion on Power10.
Use the SCHED_REORDER hook to implement Power10 specific ready list reordering.
As of now, pairing stores for store fusion is the only function being
performed.
Bootstrap/
Hi Segher,
On 8/4/21 5:29 PM, Segher Boessenkool wrote:
On Thu, Jul 29, 2021 at 08:30:48AM -0500, Bill Schmidt wrote:
+rs6000-gen-builtins: rs6000-gen-builtins.o rbtree.o
+ $(LINKER_FOR_BUILD) $(BUILD_LINKERFLAGS) $(BUILD_LDFLAGS) -o $@ \
+ $(filter-out $(BUILD_LIBDEPS), $^) $(B
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
way
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
fold-vec-lo
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...
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 alt
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?
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, bu
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 de
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 tha
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 no
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 (doubl
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 hav
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 version
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
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 su
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 hav
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
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/
* confi
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-builti
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 w
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, 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 chec
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:
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
* config/rs60
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, _mm_cvt
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 documentin
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 POWER
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, xxblend
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,
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
mall
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 re
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/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
+; M
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, Au
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 teste
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.
2021
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
+; altivec_resolve_overloaded_builtin.
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
initialization
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
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. Ne
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, _mm_ma
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 (_mm_test_all_zero
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
- _mm_cvte
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 Paul
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 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 buil
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 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 automatical
The description in rs6000-builtin.def provides for a builtin named
__builtin_altivec_xst_len_r. However, it is hand-defined in
altivec_init_builtins as __builtin_xst_len_r, against the usual naming
practice. Fix that.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions;
On 9/16/20 5:32 AM, Segher Boessenkool wrote:
On Tue, Sep 15, 2020 at 08:38:42PM -0500, Bill Schmidt wrote:
The description in rs6000-builtin.def provides for a builtin named
__builtin_altivec_xst_len_r. However, it is hand-defined in
altivec_init_builtins as __builtin_xst_len_r, against the us
This is a cleanup requested by Segher in a previous review. Most
uses of rs6000_pcrel_p are called for the current function. A
specialized version for cfun is more efficient for these uses.
(Actually all uses are called for the current function, so now
rs6000_pcrel_p is an orphan. However, I th
On 9/16/20 12:09 PM, Segher Boessenkool wrote:
On Wed, Sep 16, 2020 at 08:36:35AM -0500, Bill Schmidt wrote:
This is a cleanup requested by Segher in a previous review. Most
uses of rs6000_pcrel_p are called for the current function. A
specialized version for cfun is more efficient for these u
On 9/25/20 6:50 PM, Segher Boessenkool wrote:
On Fri, Sep 25, 2020 at 03:34:49PM -0500, will schmidt wrote:
On Fri, 2020-09-25 at 12:36 -0500, Segher Boessenkool wrote:
No, it cannot.
This is used for pdepd/pextd/cntlzdm/cnttzdm/cfuged, all of which do
need 64-bit registers to do anything sane
Hi!
https://gcc.gnu.org/PR95082 demonstrates that we don't generate correct code for
vec_cntlz_lsbb and vec_cnttz_lsbb for little-endian targets. This patch
corrects
the problem by marking the built-ins as bif_is_endian and using the correct
target patterns for each endianness. Note that the de
Hi!
[I'm resubmitting this because the filename changed with the recent conversion
from .c to .cc.]
This patch continues the refactoring started with r12-6014. I had previously
noted that the resolve_vec* routines can be further simplified by processing
the argument list earlier, so that all rou
Hi,
It was recently discovered that Clang supports a couple of variants of vec_sldw
that
GCC does not. After some discussion, we decided that these variants are
reasonable,
and GCC will also support them. This patch adds that support.
I updated an existing test and discovered it wasn't actual
Thanks! Pushed as r12-6806 with the testcase adjusted.
Bill
On 1/21/22 11:47 AM, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Jan 21, 2022 at 11:31:34AM -0600, Bill Schmidt wrote:
>> It was recently discovered that Clang supports a couple of variants of
>> vec_sldw that
>> GCC does not. After s
Adding the patch author for his information.
Thanks,
Bill
On 1/24/22 2:26 PM, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Jan 24, 2022 at 08:55:37AM -0600, Segher Boessenkool wrote:
>> Hi!
>>
>> On Thu, Jan 13, 2022 at 02:08:53PM -0300, Raoni Fassina Firmino wrote:
>>> Changes since v8[8]:
>>>
Hi!
This is a resubmission of some patches and a new submission of others.
Patches 1, 3, and 4 finish up the pending clean-up work for the new built-in
infrastructure support. Patches 2 and 5-8 fix a variety of bugs not specific
to the new infrastructure. I'm submitting these as a group primaril
This patch continues the refactoring started with r12-6014. I had previously
noted that the resolve_vec* routines can be further simplified by processing
the argument list earlier, so that all routines can use the arrays of arguments
and types. I found that this was useful for some of the routine
It was recently pointed out that we get anomalous behavior when using
__attribute__((target)) to select a CPU. As an example, when building for
-mcpu=power8 but using __attribute__((target("mcpu=power10")), it is legal
to call __builtin_vec_mod, but not vec_mod, even though these are
equivalent.
When introducing the new built-in support, I tried to match as many
existing error messages as possible. One common form was "argument X must
be a Y-bit unsigned literal". Another was "argument X must be a literal
between X' and Y', inclusive". During reviews, Segher requested that I
eventually
These built-ins were misimplemented as always having big-endian semantics.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.
Is this okay for trunk?
Thanks,
Bill
2022-01-18 Bill Schmidt
gcc/
PR target/95082
* config/rs6000/rs6000-builtin.cc (rs6000_expand
The -m[no-]fold-gimple flag was really intended primarily for internal
testing while implementing GIMPLE folding for rs6000 vector built-in
functions. It ended up leaking into other places, causing problems such
as PR103686 identifies. Let's remove it.
There are a number of tests in the testsuit
As the subject states. Fixing this is accomplished by moving the built-ins
to the correct stanzas, [altivec] and [vsx].
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.
Is this okay for trunk?
Thanks,
Bill
2022-01-27 Bill Schmidt
gcc/
* config/rs6000/rs6000-bui
PR104004 caught some misses on my part in converting to the new built-in
function infrastructure. In particular, I forgot to mark all of the "nosoft"
built-ins, and one of those should also have been marked "no32bit".
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.
Is this o
On 1/28/22 1:11 PM, Segher Boessenkool wrote:
> On Fri, Jan 28, 2022 at 11:50:19AM -0600, Bill Schmidt wrote:
>> This patch continues the refactoring started with r12-6014.
> ab3f5b71dc6e
>
>> + and the generic code will issue the appropriate error message. Skip
>> + this test for functi
On 1/28/22 2:32 PM, Segher Boessenkool wrote:
> On Fri, Jan 28, 2022 at 11:50:20AM -0600, Bill Schmidt wrote:
>> It was recently pointed out that we get anomalous behavior when using
>> __attribute__((target)) to select a CPU. As an example, when building for
>> -mcpu=power8 but using __attribut
On 1/28/22 5:24 PM, Segher Boessenkool wrote:
> On Fri, Jan 28, 2022 at 11:50:21AM -0600, Bill Schmidt wrote:
>> When introducing the new built-in support, I tried to match as many
>> existing error messages as possible. One common form was "argument X must
>> be a Y-bit unsigned literal". Anothe
On 1/31/22 11:28 AM, Segher Boessenkool wrote:
> On Mon, Jan 31, 2022 at 11:21:32AM -0600, Bill Schmidt wrote:
>> On 1/28/22 5:24 PM, Segher Boessenkool wrote:
>>> On Fri, Jan 28, 2022 at 11:50:21AM -0600, Bill Schmidt wrote:
When introducing the new built-in support, I tried to match as many
Hi Segher,
On 1/31/22 3:32 PM, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Jan 28, 2022 at 11:50:22AM -0600, Bill Schmidt wrote:
>> Continuing with the refactoring effort, this patch moves as much of the
>> target-specific built-in support code into a new file, rs6000-builtin.cc.
>> However, we ca
Hi,
I've modified the previous patch to add more explanatory commentary about
the number-of-arguments test that was previously confusing, and to convert
the switch into an if-then-else chain. The rest of the patch is unchanged.
Bootstrapped and tested on powerpc64le-linux-gnu. Is this okay for t
Hi!
As discussed, I simplified this patch by just changing how the error
message is produced:
We currently give different error messages for built-in functions that
violate range restrictions on their arguments, depending on whether we
record them as requiring an n-bit literal or a literal betwee
Hi!
Jakub, thanks for fixing this. I didn't realize the PCH implications here,
clearly...
On 2/1/22 12:33 PM, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Feb 01, 2022 at 04:27:40PM +0100, Jakub Jelinek wrote:
>> +/* PR target/104323 */
>> +/* { dg-require-effective-target powerpc_altivec_ok } *
Hi!
On 2/1/22 3:48 PM, Segher Boessenkool wrote:
> On Tue, Feb 01, 2022 at 08:49:34AM -0600, Bill Schmidt wrote:
>> I've modified the previous patch to add more explanatory commentary about
>> the number-of-arguments test that was previously confusing, and to convert
>> the switch into an if-then-
Hi!
Although the previous patch was correct, the logic around what to do when
the number of arguments is wrong was still hard to understand. It should
be better now. I'm now explicitly counting the number of expected arguments
and comparing against that. The way the argument list is represented
Hi!
PR100808 pointed out some trivial formatting issues with Power documentation
for basic ISA 3.1 built-in functions. This patch cleans those up.
Tested on powerpc64le-linux-gnu, committed as obvious.
Thanks!
Bill
2022-02-04 Bill Schmidt
gcc/
PR target/100808
* doc/extend
Hi Segher,
Thanks for all the reviews for this series! I'd like to gently ping the last
two patches.
BR,
Bill
On 1/28/22 11:50 AM, Bill Schmidt via Gcc-patches wrote:
> As the subject states. Fixing this is accomplished by moving the built-ins
> to the correct stanzas, [altive
Hi!
I observed recently that a couple of Power10 instructions and built-in functions
were somehow not implemented. This patch adds one of them (vmsumcud). Although
this isn't normally stage-4 material, this is really simple and carries no
discernible risk, so I hope it can be considered.
Bootst
Hi!
On 2/7/22 5:05 PM, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Feb 07, 2022 at 04:20:24PM -0600, Bill Schmidt wrote:
>> I observed recently that a couple of Power10 instructions and built-in
>> functions
>> were somehow not implemented. This patch adds one of them (vmsumcud).
>> Although
>
On 2/8/22 9:45 AM, Segher Boessenkool wrote:
> On Mon, Feb 07, 2022 at 10:06:36PM -0600, Bill Schmidt wrote:
>> On 2/7/22 5:05 PM, Segher Boessenkool wrote:
>>> On Mon, Feb 07, 2022 at 04:20:24PM -0600, Bill Schmidt wrote:
I observed recently that a couple of Power10 instructions and built-i
Hi!
>From some discussion today, I think we want to limit the scope of
this patch to just the power8-fusion flag that's causing trouble for
now, given stage 4. We've talked about making power8-fusion a do-
nothing flag, since it doesn't add much benefit now and probably
shouldn't be a separate fl
Hi!
Due to a pasto error in the documentation, vec_replace_unaligned was
implemented with the same function prototypes as vec_replace_elt. It was
intended that vec_replace_unaligned always specify output vectors as having
type vector unsigned char, to emphasize that elements are potentially
misal
Hi!
After vec_clrl and vec_clrr were implemented and during review of the
documentation, it was agreed to change their names to vec_clr_first and
vec_clr_last to more clearly describe their bi-endian semantics. ("Left"
and "right" are the wrong terms to be using.) It looks like I neglected
to ma
Hi!
This is a backport from mainline 3f30f2d1dbb3228b8468b26239fe60c2974ce2ac.
These built-ins were misimplemented as always having big-endian semantics.
Because the built-in infrastructure has changed, the modifications to the
source are different but achieve the same purpose. The modifications
Hi!
On 2/10/22 2:06 PM, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Feb 10, 2022 at 12:22:28PM -0600, Bill Schmidt wrote:
>> This is a backport from mainline 3f30f2d1dbb3228b8468b26239fe60c2974ce2ac.
>> These built-ins were misimplemented as always having big-endian semantics.
> What is different
Hi!
On 2/10/22 2:50 PM, Segher Boessenkool wrote:
> On Thu, Feb 10, 2022 at 12:22:28PM -0600, Bill Schmidt wrote:
>> This is a backport from mainline 3f30f2d1dbb3228b8468b26239fe60c2974ce2ac.
>> These built-ins were misimplemented as always having big-endian semantics.
>>
>> Because the built-in i
Hi!
On 2/10/22 4:11 PM, Segher Boessenkool wrote:
> On Thu, Feb 10, 2022 at 03:17:05PM -0600, Bill Schmidt wrote:
/* 1 argument vector functions added in ISA 3.0 (power9). */
-BU_P9V_AV_1 (VCLZLSBB_V16QI, "vclzlsbb_v16qi",CONST, vclzlsbb_v16qi)
-BU_P9V_AV_1 (VCLZLSBB_V8HI, "vc
Fine. I withdraw the patch request, and will remove my name from
the bugzilla. Somebody else can deal with it. I have more important
things to worry about.
Bill
On 2/11/22 1:31 AM, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Feb 10, 2022 at 04:28:02PM -0600, Bill Schmidt wrote:
>> On 2/10/22 4
On 11/17/21 6:44 AM, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Nov 16, 2021 at 02:26:22PM -0600, Bill Schmidt wrote:
>> Hi! I recently submitted [1] to make adjustments to test cases for the new
>> builtins
>> support, mostly due to error messages changing for consistency. Thanks for
>> the
On 11/17/21 10:54 AM, Paul A. Clarke wrote:
> On Tue, Nov 16, 2021 at 11:12:35AM -0600, Bill Schmidt via Gcc-patches wrote:
>> Hi! During a previous patch review, Segher asked that I provide better
>> messages when builtins are unavailable because they require both a minimum
Hi! This patch is broken out of the previous patch for all the builtins test
suite adjustments. Here we have some slight changes in error messages due to
how the internals have changed between the old and new builtins methods.
For scalar-extract-exp-2.c we change:
error: '__builtin_vec_scalar_
On 11/17/21 3:32 PM, Segher Boessenkool wrote:
> On Wed, Nov 17, 2021 at 02:58:54PM -0600, Bill Schmidt wrote:
>> Hi! This patch is broken out of the previous patch for all the builtins test
>> suite adjustments. Here we have some slight changes in error messages due to
>> how the internals hav
Hi!
On 11/17/21 5:06 PM, Bill Schmidt wrote:
> On 11/17/21 3:32 PM, Segher Boessenkool wrote:
>> On Wed, Nov 17, 2021 at 02:58:54PM -0600, Bill Schmidt wrote:
>>> Hi! This patch is broken out of the previous patch for all the builtins
>>> test
>>> suite adjustments. Here we have some slight cha
Hi! This patch is broken out from the previous patch for builtins test suite
changes. With the old builtins support, this test case produces:
warning: implicit declaration of function '__builtin_byte_in_set'; did you
mean '__builtin_byte_in_range'?
With the new support, it produces:
error:
Hi! This patch is broken out from the patch with test suite changes for the
new builtins support.
With the old builtins support, cmpb-2.c produces:
warning: implicit declaration of function '__builtin_cmpb; did you mean
'__builtin_bcmp'?
With the new support, it produces:
error: '__builtin_
Hi! This patch is broken out from the test case patch for the new builtins
support.
The old builtins code performs gimple folding on 128-bit compares. This
results in correct but very inefficient code. (I suspect we may be
missing some optab entries, misleading gimple into 64-bit emulation.)
1 - 100 of 617 matches
Mail list logo
