t; overload:
__builtin_vec_scalar_test_neg
The latter maps to three builtins of the appropriate type.
The revised test case uses the "real" overload instead, and otherwise the
changes to the error messages are the same as for all the other cases.
2021-11-17 Bill Schmidt
gcc/tests
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
>&
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 ad
a result.
Tested on powerpc64le-linux-gnu and powerpc-linux-gnu (-m32/-m64) with no
regressions. Is this okay for trunk?
Thanks!
Bill
2021-11-17 Bill Schmidt
gcc/testsuite/
* gcc.target/powerpc/byte-in-set-2.c: Adjust error message.
---
gcc/testsuite/gcc.target/powerpc/byte-in-set-2.c |
arget" are used. The new
support initializes all builtins, and waits until expand time to determine
whether or not they are enabled. Besides added flexibility, we also get
better error messages as a result.
The case for cmpb32-2.c is similar.
Tested on powerpc64le-linux-gnu and powerpc64-linux
x-gnu (-m32/-m64) with
no regressions. Is this okay for trunk?
Thanks!
Bill
2021-11-17 Bill Schmidt
gcc/testsuite/
* gcc.target/powerpc/int_128bit-runnable.c: Adjust instruction
counts since we do better by not gimple-folding some builtins.
---
gcc/testsuite/gcc.target/po
owerpc64le-linux-gnu and powerpc64-linux-gnu (-m32/-m64) with
no regressions. is this okay for trunk?
Thanks!
Bill
2021-11-17 Bill Schmidt
gcc/testsuite/
* gcc.target/powerpc/pr80315-1.c: Adjust error message.
* gcc.target/powerpc/pr80315-2.c: Likewise.
*
Bill Schmidt
gcc/testsuite/
* gcc.target/powerpc/pragma_misc9.c: Adjust error message.
---
gcc/testsuite/gcc.target/powerpc/pragma_misc9.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/pragma_misc9.c
b/gcc/testsuite/gcc.target
Hi!
On 11/18/21 10:22 AM, Segher Boessenkool wrote:
> On Thu, Nov 18, 2021 at 10:09:53AM -0600, Bill Schmidt wrote:
>> 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
messages. In
particular, some messages are improved because previously they did not
admit the possibility that an argument could hold a variable.
Tested on powerpc64le-linux-gnu and powerpc64-linux-gnu (-m32/-m64)
with no regressions. Is this okay for trunk?
Thanks!
Bill
2021-11-17 Bill Schmid
Hi! Thanks for all the recent reviews and conversations on the builtins
infrastructure patches. I've posted a lot of stuff in the last couple
of days, so I thought it might be useful to summarize which patches still
need review. No rush, just trying to make it easier to consume...
https://gcc.g
On 11/18/21 3:16 PM, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Nov 17, 2021 at 05:06:05PM -0600, Bill Schmidt wrote:
>>> I don't like that at all. The user didn't write the _vsx thing, and it
>>> isn't documented either (neither is the _vec one, but
Hi!
On 11/18/21 3:32 PM, Segher Boessenkool wrote:
> On Thu, Nov 18, 2021 at 03:30:48PM -0600, Bill Schmidt wrote:
>> On 11/18/21 3:16 PM, Segher Boessenkool wrote:
>>> Hi!
>>>
>>> On Wed, Nov 17, 2021 at 05:06:05PM -0600, Bill Schmidt wrote:
>>>>&g
Hi!
On 11/19/21 8:49 AM, Michael Meissner wrote:
> The next set of 3 patches add zero cycle move support to the Power10. Zero
> cycle moves are where the move to LR/CTR/TAR register that is adjacent to the
> jump to LR/CTR/TAR register can be fused together.
>
> At the moment, these set of three
Hi Mike,
On 11/19/21 8:55 AM, Michael Meissner wrote:
> Set power10 fusion if -mtune=power10.
>
> In doing the patch for zero cycle moves for switch statements and indirect
> jumps, I noticed the fusion support is only done if -mcpu=power10. This
> option
> enables power10 fusion if we use -mtun
Hi Mike,
Thanks for this patch!
On 11/19/21 8:53 AM, Michael Meissner wrote:
> Add power10 zero cycle moves for switches.
>
> Power10 will fuse adjacenet 'mtctr' and 'bctr' instructions to form zero
> cycle moves. This code exploits this fusion opportunity.
>
> I have built bootstrapped compiler
suite, since we
don't test for "note" diagnostics anywhere.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is
this okay for trunk?
Thanks!
Bill
2021-11-23 Bill Schmidt
gcc/
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builti
Hi!
Paul Clarke pointed out to me that I had wrongly used a compile-time check
instead of a run-time check in this executable test. This patch fixes
that. I also fixed a typo in a string that caught my eye.
Tested on powerpc64le-linux-gnu, committed as obvious.
Thanks!
Bill
2021-11-23 Bill
-linux-gnu with no regressions. Is this
okay for trunk?
Thanks!
Bill
2021-12-01 Bill Schmidt
gcc/
PR target/102347
* config/rs6000/rs6000-c.c (rs6000-builtins.h): Stop including.
(rs6000-internal.h): Include.
(altivec_resolve_new_overloaded_builtin): Mo
On 11/16/21 12:56 PM, Bill Schmidt wrote:
> Hi! I previously posted [1] to correct some problems with the new builtins
> support targeting 32-bit code gen. Based on the discussion, I've made some
> adjustments and would like to submit this for consideration.
>
> We eventuall
Hi! I'd like to ping this patch. Segher had objected to the change in
diagnostics,
but I hope we've solved that now with the better informational message [1].
Thanks!
Bill
[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585250.html
On 11/17/21 2:58 PM, Bill Schmidt w
Hi! I'd like to ping this patch.
Thanks!
Bill
On 11/18/21 7:47 AM, Bill Schmidt wrote:
> 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 dec
Hi! I'd like to ping this patch.
Thanks!
Bill
On 11/18/21 10:15 AM, Bill Schmidt wrote:
> Hi! This patch is broken out from the test case patch for the new
> builtins support.
>
> One advantage of the new builtins support is uniform error messages for
> arguments wi
Hi! I'd like to ping this patch.
Thanks!
Bill
On 11/18/21 10:18 AM, Bill Schmidt wrote:
> Hi! This patch is broken out from the test suite patch for the new
> builtins support. This one is just a minor adjustment for the error
> message wording.
>
> Tested on power
Hi! I'd like to ping this patch.
Thanks!
Bill
On 11/18/21 10:36 AM, Bill Schmidt wrote:
> Hi! This is the last patch broken out of the previous test suite patch
> for the new builtins support.
>
> One advantage of the new builtins support is uniform error messages for
On 12/1/21 11:21 AM, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Dec 01, 2021 at 09:29:42AM -0600, Bill Schmidt wrote:
>> Recently Kewen fixed a problem in the old builtins support where
>> rs6000_builtin_decl prematurely indicated that a target builtin is
>> unavaila
Hi!
On 12/1/21 3:08 PM, Segher Boessenkool wrote:
> On Tue, Nov 16, 2021 at 12:56:52PM -0600, Bill Schmidt wrote:
>> Hi! I previously posted [1] to correct some problems with the new builtins
>> support targeting 32-bit code gen. Based on the discussion, I've made some
>
Hi!
On 12/1/21 4:29 PM, Segher Boessenkool wrote:
> On Thu, Nov 18, 2021 at 10:15:21AM -0600, Bill Schmidt wrote:
>> Hi! This patch is broken out from the test case patch for the new
>> builtins support.
>>
>> One advantage of the new builtins support is uniform erro
Hi!
On 12/1/21 5:00 PM, Segher Boessenkool wrote:
> On Thu, Nov 18, 2021 at 10:36:52AM -0600, Bill Schmidt wrote:
>> Hi! This is the last patch broken out of the previous test suite patch
>> for the new builtins support.
> Whew :-)
>
>> One advantage of the new builti
we're not going to do
that anymore, and the remnants of that code will be removed shortly.
Regstrap is in progress on powerpc64le-linux-gnu. Assuming no problems, is this
okay to commit to trunk?
Thanks!
Bill
2021-12-02 Bill Schmidt
gcc/
* config/rs6000/rs6
On 12/3/21 10:26 AM, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Dec 02, 2021 at 04:53:18PM -0600, Bill Schmidt wrote:
>> I discovered this bug while working on patches to remove the old built-ins
>> infrastructure. I missed a spot in converting from the rs6000_builti
From: Bill Schmidt
Hi!
Now that the new built-in function support is all upstream and enabled, it
seems safe and prudent to remove the old code to avoid confusion. I broke this
up to the extent possible, but the first patch is a bit large and messy because
so many dead functions have to be
From: Bill Schmidt
Hi!
This patch just renames a file and updates the build machinery accordingly.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
okay for trunk?
Thanks!
Bill
2021-12-02 Bill Schmidt
gcc/
* config/rs6000/rs6000-builtin-new.def
From: Bill Schmidt
Hi!
While we had two sets of built-in functionality at the same time, I put "new"
in the names of quite a few functions. Time to undo that.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
okay for trunk?
Thanks!
Bill
2021-12-02 Bi
From: Bill Schmidt
Hi!
While we had two sets of built-in infrastructure at once, I added _x as a
suffix to two arrays to disambiguate the old and new versions. Time to fix
that also.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
okay for trunk?
Thanks!
Bill
I had difficulty with patch 1/6 being too large, and there have been some small
upstream changes in this area, so I will resubmit this series shortly. There
were also problems with my SMTP server for some of the CCs as well...
Sorry for the churn!
Bill
On 12/3/21 12:22 PM, Bill Schmidt wrote
functions for AIX, and
his fix for that required me to re-spin the patches. I also generated the diff
with a more efficient algorithm to reduce the patch size. Otherwise this
series is identical to V1.
Thanks!
Bill
Bill Schmidt (6):
rs6000: Remove new_builtins_are_live and dead code it was guarding
Hi!
This patch just renames a file and updates the build machinery accordingly.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
okay for trunk?
Thanks!
Bill
2021-12-02 Bill Schmidt
gcc/
* config/rs6000/rs6000-builtin-new.def: Rename to
Hi!
The old rs6000-builtin.def file is no longer needed. Remove it and the code
that depends on it.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
okay for trunk?
Thanks!
Bill
2021-12-02 Bill Schmidt
gcc/
* config/rs6000/rs6000-builtin.def: Delete
Hi!
While we had two sets of built-in functionality at the same time, I put "new"
in the names of quite a few functions. Time to undo that.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
okay for trunk?
Thanks!
Bill
2021-12-02 Bill Schm
Hi!
While we had two sets of built-in infrastructure at once, I added _x as a
suffix to two arrays to disambiguate the old and new versions. Time to fix
that also.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
okay for trunk?
Thanks!
Bill
2021-12-06 Bill
egressions. Is this
okay for trunk?
Thanks!
Bill
2021-12-09 Bill Schmidt
gcc/
* config/rs6000/rs6000-c.c (resolution): New enum.
(resolve_VEC_MUL): New function.
(resolve_VEC_CMPNE): Likewise.
(resolve_VEC_ADDE_SUBE): Likewise.
(resolve_VEC_ADDEC_SUBEC)
I forgot to point out that this patch is dependent on the pending patches
to remove the old builtins code.
Thanks,
Bill
On 12/9/21 12:33 PM, Bill Schmidt via Gcc-patches wrote:
> Hi!
>
> While replacing the built-in machinery, we agreed to defer some necessary
> refactoring of
eview, unfortunately. Just be aware that generally we aren't changing
the logic and functionality of overload handling.
2021-08-31 Bill Schmidt
gcc/
* config/rs6000/rs6000-c.c (rs6000-builtins.h): New include.
(altivec_resolve_new_overloaded_builtin): New fo
.
Thanks again for all of the helpful reviews so far!
Bill
Bill Schmidt (18):
rs6000: Handle overloads during program parsing
rs6000: Move __builtin_mffsl to the [always] stanza
rs6000: Handle gimple folding of target built-ins
rs6000: Handle some recent MMA builtin changes
rs60
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
ntion that adds _INTERNAL to
the builtin index name remains.
The rest of the patch is just duplicating Peter's patch, using the new
builtin infrastructure.
2021-08-23 Bill Schmidt
gcc/
* config/rs6000/rs6000-builtin-new.def (ASSEMBLE_ACC): Add mmaint flag.
(ASSEMBLE_
.
2021-08-31 Bill Schmidt
gcc/
* config/rs6000/rs6000-call.c (rs6000_gimple_fold_new_builtin):
New forward decl.
(rs6000_gimple_fold_builtin): Call rs6000_gimple_fold_new_builtin.
(rs6000_new_builtin_valid_without_lhs): New function
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 fun
that are
restricted to specific values or ranges.
Note that these six patches must be pushed together, because otherwise
unused parameter warnings in the stub functions will prevent bootstrap.
If preferred, I can flag them unused to remove this restriction.
2021-08-31 Bill Schmidt
variable altivec_builtin_mask_for_load is initialized.
2021-09-01 Bill Schmidt
gcc/
* config/rs6000/rs6000-call.c (rs6000_invalid_new_builtin):
Implement.
(rs6000_expand_ldst_mask): Likewise.
(rs6000_init_builtins): Initialize altivec_builtin_mask_for_load
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.
---
gcc/config
altivec_expand_lxvr_builtin
= stv_expand builtin replaces altivec_expand_stv_builtin
In all cases, there are no logic changes except that some code was
already factored out into rs6000_expand_new_builtin.
2021-09-01 Bill Schmidt
gcc/
* config/rs6000/rs6000-call.c (elemrev_icode): Implement
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
bit" attributes,
which is straightforward. These just do icode substitution.
2021-09-01 Bill Schmidt
gcc/
* config/rs6000/rs6000-call.c (new_htm_spr_num): New function.
(new_htm_expand_builtin): Implement.
(rs6000_expand_new_builtin): Handle 32-bit and endian ca
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
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
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
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-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-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-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
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.
fm
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
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 f
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 resource
+vector signed __int128
+foo4 (signed long a, signed long *b)
+{
+ return vec_xl_sext (a, b);
+}
+
+/* { dg-final { scan-assembler-times {\mvextsd2q\M} 4 } } */
+/* { dg-final { scan-assembler-times {\mvextsb2d\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mvextsh2d\M} 1 } } */
+/* { dg-final { sc
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 t
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 p9_vecto
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
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 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
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 the
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 Sc
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 undo
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 exaggerated
c64le-unknown-linux-gnu with no regressions.
Is this okay for trunk?
Thanks!
Bill
2021-09-21 Bill Schmidt
gcc/
PR target/102024
* config/rs6000/rs6000-call.c (rs6000_aggregate_candidate): Detect
zero-width bit fields and return indi
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
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
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
infrastructure where we were
using the VSX form of the VEC_COPYSIGN built-in when we should default to
the VMX form.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions.
Is this okay for trunk?
Thanks!
Bill
2021-09-24 Bill Schmidt
gcc/
PR target/101985
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 i
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 rewrit
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
For posterity: This was discussed briefly on IRC, and Segher approved with
some
simplifications and a request to implement a fail/retry check.
Thanks,
Bill
On 11/3/21 10:02 AM, Jonathan Wakely wrote:
> On Wed, 3 Nov 2021 at 15:01, Jonathan Wakely wrote: Any feedback from POWER
> maintainers a
On 11/5/21 7:44 AM, Jonathan Wakely wrote:
> On Thu, 4 Nov 2021 at 20:44, Bill Schmidt wrote: For posterity: This was
> discussed briefly on IRC, and Segher approved with some simplifications and a
> request to implement a fail/retry check. Here's what I have now. No more
>
d.
Thanks again!
Bill
On 11/3/21 8:24 PM, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Sep 01, 2021 at 11:13:47AM -0500, Bill Schmidt wrote:
>> Provide replacements for htm_spr_num and htm_expand_builtin. No logic
>> changes are intended here, as usual.
Sorry for the misunderstanding. What I meant is the 6 patches entitled
"Builtin expansion, part N".
I still have 6-7 patches left to look at.
Thanks!
Bill
On 11/7/21 3:05 PM, Segher Boessenkool wrote:
> Hi!
>
> On Sun, Nov 07, 2021 at 09:28:09AM -0600, Bill Schmidt wrote:
&
On 11/5/21 6:50 PM, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Sep 01, 2021 at 11:13:54AM -0500, Bill Schmidt wrote:
>> +/* Escape-newline support. For readability, we prefer to allow developers
>> + to use escape-newline to continue long lines to the next one. We
>&g
On 11/5/21 4:34 PM, Segher Boessenkool wrote:
> On Wed, Sep 01, 2021 at 11:13:50AM -0500, Bill Schmidt wrote:
>> * config/rs6000/rs6000-call.c (rs6000_debug_type): New function.
>> (def_builtin): Change debug formatting for easier parsing and
>> inc
e. I
corrected that as part of this patch.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
okay for trunk?
Thanks!
Bill
2021-11-09 Bill Schmidt
gcc/
* config/rs6000/rs6000-call.c (rs6000_gimple_fold_new_builtin):
Disable gimple fold for RS6000_
th no
regressions. Is this okay for trunk?
Thanks!
Bill
2021-09-02 Bill Schmidt
gcc/
* config/rs6000/rs6000-builtin-new.def (CMPB): Flag as no32bit.
(BPERMD): Flag as 32bit.
(UNPACK_TD): Return unsigned long long instead of unsigned long.
(SET_TEXASR): Pass uns
On 11/10/21 2:33 AM, Segher Boessenkool wrote:
> On Tue, Nov 09, 2021 at 03:46:54PM -0600, Bill Schmidt wrote:
>> Hi! Some time ago I realized I hadn't tested the new builtin support
>> against 32-bit
>> big-endian in quite a while. When I did, I found a handful
Hi!
On 11/11/21 7:11 AM, Segher Boessenkool wrote:
> On Wed, Nov 10, 2021 at 03:28:18PM -0600, Bill Schmidt wrote:
>> On 11/10/21 2:33 AM, Segher Boessenkool wrote:
>>> On Tue, Nov 09, 2021 at 03:46:54PM -0600, Bill Schmidt wrote:
>>>>* config/rs6000/rs6000-b
Hi Segher,
[Sorry to be answering these out of order...]
On 11/5/21 5:37 PM, Segher Boessenkool wrote:
> On Wed, Sep 01, 2021 at 11:13:52AM -0500, Bill Schmidt wrote:
>> * gcc.target/powerpc/bfp/scalar-extract-exp-2.c: Adjust.
> My favourite changelog entry! But, adjust to wh
Hi! Per previous discussion, committed the following as obvious.
commit 8a8458ac6bbc4263dd2c1ee55979b29fc7195794
Author: Bill Schmidt
Date: Thu Nov 11 14:36:04 2021 -0600
rs6000: Fix test_mffsl.c to require Power9 support
2021-11-11 Bill Schmidt
gcc/testsuite
On 11/11/21 2:06 PM, Bill Schmidt wrote:
>
>>> --- a/gcc/testsuite/gcc.target/powerpc/int_128bit-runnable.c
>>> +++ b/gcc/testsuite/gcc.target/powerpc/int_128bit-runnable.c
>>> @@ -11,9 +11,9 @@
>>> /* { dg-final { scan-assembler-times {\mvrlq\M} 2 } } */
&g
On 11/11/21 10:50 AM, Bill Schmidt wrote:
> On 11/11/21 7:11 AM, Segher Boessenkool wrote:
>> void f(long x) { __builtin_set_texasr(x); }
>>
>> built with -m32 -mpowerpc64 gives (in the expand dump):
>>
>> void f (long int x)
>> {
>> long long un
Hi Segher,
On 11/14/21 9:29 AM, Segher Boessenkool wrote:
> Hi!
>
> On Sun, Nov 14, 2021 at 08:17:41AM -0600, Bill Schmidt wrote:
>> On 11/11/21 10:50 AM, Bill Schmidt wrote:
>>> On 11/11/21 7:11 AM, Segher Boessenkool wrote:
>>>> void f(long x) { __builtin_s
Hi Hao Chen,
I don't understand. This patch was already approved and you committed it. :-)
I know
because I needed to make corresponding adjustments to the new builtins code.
Thanks,
Bill
On 11/15/21 8:16 PM, HAO CHEN GUI wrote:
> Hi,
>
> The patch optimizes the code generation for vec_xl_
1001 - 1100 of 1523 matches
Mail list logo
