Commit r14-3258-ge7a36e4715c716 increased the amount of folding we perform,
leading to better code. Update the expected instruction counts to match the
the number of associated vec_* built-in calls.
Tested on powerpc64le-linux with no regressions. Ok for mainline?
Peter
gcc/testsuite/
On 8/25/23 6:20 AM, Kewen.Lin wrote:
> Assuming the current PCREL_SUPPORTED_BY_OS unchanged, when
> PCREL_SUPPORTED_BY_OS is true, all its required conditions are
> satisfied, it should be safe. while PCREL_SUPPORTED_BY_OS is
> false, it means the given subtarget doesn't support it, or one
> or
On 8/24/23 12:56 AM, Kewen.Lin wrote:
> By looking into the uses of function rs6000_pcrel_p, I think we can
> just replace it with TARGET_PCREL. Previously we don't require PCREL
> unset for any unsupported target/OS, so we need rs6000_pcrel_p() to
> ensure it's really supported in those use
On 8/24/23 12:35 PM, Michael Meissner wrote:
> On Thu, Jul 20, 2023 at 10:05:28AM +0530, jeevitha wrote:
>> gcc/
>> PR target/110411
>> * config/rs6000/rs6000.h (enum rs6000_builtin_type_index): Add fields
>> to hold PTImode type.
>> * config/rs6000/rs6000-builtin.cc
On 8/21/23 8:51 PM, Kewen.Lin wrote:
>> The following patch has been bootstrapped and regtested on powerpc64-linux.
>
> I think we should test this on powerpc64le-linux P8 or P9 (no P10) as well.
That's a good idea!
> I think this should be moved to be with the hunk on PCREL:
>
> /* If the
On 8/2/23 8:23 AM, Vladimir Makarov wrote:
>>> gcc/
>>> PR rtl-optimization/PR110254
>>> * ira-color.cc (improve_allocation): Update array
>
> I guess you missed the next line in the changelog. I suspect it should be
> "Update array allocated_hard_reg_p."
>
> Please, fix it before
On 8/16/23 7:19 PM, Carl Love wrote:
> +(define_insn "dfp_dquan_"
> + [(set (match_operand:DDTD 0 "gpc_reg_operand" "=d")
> +(unspec:DDTD [(match_operand:DDTD 1 "gpc_reg_operand" "d")
> + (match_operand:DDTD 2 "gpc_reg_operand" "d")
> +
On 7/19/23 11:46 AM, jeevitha via Gcc-patches wrote:
> gcc/
> PR target/110411
> * config/rs6000/mma.md (define_insn_and_split movoo): Disallow
> AltiVec address in movoo and movxo pattern.
No need to mention movxo here, since the next change covers movxo.
And maybe better as
On 6/29/23 4:31 AM, Kewen.Lin via Gcc-patches wrote:
> This is okay for trunk (no backports needed btw), this fix can even be
> taken as obvious, thanks!
>
>>
>> 2023-06-07 Jeevitha Palanisamy
>>
>> gcc/
>> PR target/106907
>
> One curious question is that this PR106907 seemed not to
On 7/10/23 11:47 AM, Peter Bergner wrote:
> While helping someone on the team debug an issue, I noticed some redundant
> tests in a couple of our predicates which can be removed. I'm going to
> commit the following as obvious once bootstrap and regtesting come back
> clean.
>
> Peter
>
>
>
On 7/10/23 2:18 PM, Carl Love wrote:
> + /* Get the current FPSCR fields, bits 29:31 (DRN) and bits 56:63 (VE, OE,
> UE,
> + ZE, XE, NI, RN) from the FPSCR and return them. */
The 'Z' above should line up directly under the 'G' in Get.
> - /* Insert new RN mode into FSCPR. */
> -
While helping someone on the team debug an issue, I noticed some redundant
tests in a couple of our predicates which can be removed. I'm going to
commit the following as obvious once bootstrap and regtesting come back
clean.
Peter
rs6000: Remove redundant MEM_P predicate usage
The
On 7/6/23 6:28 PM, Segher Boessenkool wrote:
> On Thu, Jul 06, 2023 at 02:48:19PM -0500, Peter Bergner wrote:
>> On 7/6/23 12:33 PM, Segher Boessenkool wrote:
>>> On Wed, Jul 05, 2023 at 05:21:18PM +0530, P Jeevitha wrote:
--- a/gcc/config/rs6000/rs6000.cc
+++
On 7/7/23 12:08 AM, Kewen.Lin wrote:
> on 2023/7/7 07:00, Peter Bergner wrote:
>> On 7/6/23 5:54 PM, Peter Bergner wrote:
>>> On 6/30/23 7:58 PM, Carl Love via Gcc-patches wrote:
+++ b/gcc/testsuite/gcc.target/powerpc/test_fpscr_rn_builtin_2.c
@@ -0,0 +1,153 @@
+/* { dg-do run {
On 7/6/23 5:54 PM, Peter Bergner wrote:
> On 6/30/23 7:58 PM, Carl Love via Gcc-patches wrote:
>> +++ b/gcc/testsuite/gcc.target/powerpc/test_fpscr_rn_builtin_2.c
>> @@ -0,0 +1,153 @@
>> +/* { dg-do run { target { powerpc*-*-* } } } */
>
> powerpc*-*-* is the default for this test directory, so
On 6/30/23 7:58 PM, Carl Love via Gcc-patches wrote:
> rs6000, __builtin_set_fpscr_rn add retrun value
s/retrun/return/
Maybe better written as:
rs6000: Add return value to __builtin_set_fpscr_rn
> Change the return value from void to double. The return value consists of
> the FPSCR fields
On 7/6/23 12:33 PM, Segher Boessenkool wrote:
> On Wed, Jul 05, 2023 at 05:21:18PM +0530, P Jeevitha wrote:
>> --- a/gcc/config/rs6000/rs6000.cc
>> +++ b/gcc/config/rs6000/rs6000.cc
>> @@ -9894,6 +9894,8 @@ rs6000_legitimate_address_p (machine_mode mode, rtx x,
>> bool reg_ok_strict)
>>
>>
On 6/28/23 3:07 AM, Kewen.Lin wrote:
> I think the reason why we need to check common_deferred_options is at this
> time
> we can't distinguish the fixed_regs[2] is from the initialization or command
> line
> user explicit specification. But could we just update the FIXED_REGISTERS
> without
>
On 6/30/23 6:50 PM, Carl Love wrote:
> With a little help from Peter and Julian Wang. Objdump decodes some of
> the xxlor instructions as xxmr instsructions. The xxmr is a new
> mnemonic which will be out in the next ISA. But objdump already
> produces it. So if you add the counts for grep
On 6/30/23 5:20 PM, Carl Love wrote:
> So, we have the issue that looking at the assembly gives different
> instruction counts then what
>
>dg-final { scan-assembler-times {\mxxlor\M} }
>
> comes up with???
I recommend not even counting xxlor at all, since the majority of
them come from
On 6/22/23 10:30 PM, Ian Lance Taylor wrote:
> On Thu, Jun 22, 2023, 4: 47 PM Peter Bergner
> wrote: On 6/22/23 6: 37 PM, Peter Bergner via Gcc-patches wrote: > On 6/16/23
> >> On Fri, Jun 16, 2023 at 9:00 AM Paul E. Murphy via Gcc-patches
> >> mailto:gcc-
On 6/29/23 4:13 AM, Kewen.Lin wrote:
> on 2023/6/19 23:57, Carl Love wrote:
>> The following patch changes the return type of the
>> __builtin_set_fpscr_rn builtin from void to double. The return value
>> is the current value of the various FPSCR fields DRN, VE, OE, UE, ZE,
>> XE, NI, RN bit
On 6/1/23 11:54 PM, Ajit Agarwal via Gcc-patches wrote:
>
>
> On 01/06/23 2:06 pm, Bernhard Reutner-Fischer wrote:
>> On 1 June 2023 09:20:08 CEST, Ajit Agarwal wrote:
>>> Hello All:
>>>
>>> This patch improves code sinking pass to sink statements before call to
>>> reduce
>>> register
On 6/21/23 11:20 AM, Paul E Murphy via Gcc-patches wrote:
>
>
> On 6/19/23 3:39 AM, Thomas Schwinge wrote:
>> Hi Paul!
>>
>> On 2023-06-16T11:00:02-0500, "Paul E. Murphy via Gcc-patches"
>> wrote:
>>> This was noticed when fixing the gccgo usage of the macro, the
>>> rust usage is very
On 6/22/23 6:37 PM, Peter Bergner via Gcc-patches wrote:
> On 6/16/23 12:01 PM, Ian Lance Taylor via Gcc-patches wrote:
>> On Fri, Jun 16, 2023 at 9:00 AM Paul E. Murphy via Gcc-patches
>> wrote:
>>>
>>> TARGET_AIX is defined to a non-zero value on linux and ma
On 6/16/23 12:01 PM, Ian Lance Taylor via Gcc-patches wrote:
> On Fri, Jun 16, 2023 at 9:00 AM Paul E. Murphy via Gcc-patches
> wrote:
>>
>> TARGET_AIX is defined to a non-zero value on linux and maybe other
>> powerpc64le targets. This leads to unexpected behavior such as
>> dropping the
On 6/12/23 6:18 AM, P Jeevitha wrote:
> Bitwise xor performed on bool
> is similar to checking inequality. So changed to inequality
> operator (!=) instead of bitwise xor (^).
[snip'
> - if (swapped ^ !BYTES_BIG_ENDIAN
[snip]
> + if (swapped != !BYTES_BIG_ENDIAN
I know Andreas
This is not a review of the patch itself, but...
On 5/31/23 2:01 AM, Ajit Agarwal wrote:
> tree-ssa-sink: Improve code sinking pass
>
> Code Sinking sinks the blocks after call.This increases register pressure
> for callee-saved registers. Improves code sinking before call in the use
> blocks or
On 5/22/23 4:04 AM, Kewen.Lin wrote:
> on 2023/5/11 02:06, Carl Love via Gcc-patches wrote:
>> @@ -3161,12 +3161,15 @@
>>void __builtin_altivec_tr_stxvrbx (vsq, signed long, signed char *);
>> TR_STXVRBX vsx_stxvrbx {stvec}
>>
>> - void __builtin_altivec_tr_stxvrhx (vsq, signed long,
On 5/24/23 10:20 AM, Carl Love wrote:
> Extending the builtin to pre Power 9 is straight forward and I agree
> would make good sense to do.
>
> I am a bit concerned on how to extend __builtin_set_fpscr_rn to add the
> new functionality. Peter suggests overloading the builtin to either
> return
On 5/23/23 12:24 AM, Kewen.Lin wrote:
> on 2023/5/23 01:31, Carl Love wrote:
>> The builtins were requested for use in GLibC. As of version 2.31 they
>> were added as inline asm. They requested a builtin so the asm could be
>> removed.
>
> So IMHO we also want the similar support for mffscrn,
On 5/10/23 1:06 PM, Carl Love wrote:
> - void __builtin_altivec_tr_stxvrhx (vsq, signed long, signed int *);
> + void __builtin_altivec_tr_stxvrhx (vsq, signed long, signed short *);
> TR_STXVRHX vsx_stxvrhx {stvec}
>
> - void __builtin_altivec_tr_stxvrwx (vsq, signed long, signed short
On 5/18/23 6:16 AM, Ajit Agarwal via Gcc-patches wrote:
> -/* { dg-final { scan-assembler-times {\mrldicl\M} 7 { target { le } } } } */
> +/* { dg-final { scan-assembler-times {\mrldicl\M} 5 { target { le } } } } */
> /* { dg-final { scan-assembler-times {\mrldicl\M} 4 { target { lp64 && be }
>
On 5/10/23 2:34 AM, Andreas Schwab wrote:
> On Mai 09 2023, Peter Bergner via Gcc-patches wrote:
>> I'm sorry to be dense, but can you point to the specific line? In my
>> $GCC_BUILD/Makefile, the only mention of LD_LIBRARY_PATH is:
>>
>> RPATH_ENVVAR = LD_LIBRARY_
On 5/9/23 3:50 PM, Andreas Schwab wrote:
> On Mai 09 2023, Peter Bergner via Gcc-patches wrote:
>
>> It's almost as if the top level build machinery
>> adds a LD_LIBRARY_PATH=...
>
> See how the toplevel Makefile sets LD_LIBRARY_PATH (via RPATH_ENVVAR) if
> gcc-b
On 5/5/23 4:42 PM, Jakub Jelinek wrote:
> On Thu, May 04, 2023 at 02:29:34PM -0500, Peter Bergner wrote:
>> Merged from upstream libffi commit: 464b4b66e3cf3b5489e730c1466ee1bf825560e0
>>
>> 2023-05-03 Dan Horák
>>
>> libffi/
>> PR libffi/109447
>> * src/powerpc/ffi_linux64.c
On 5/4/23 2:29 PM, Peter Bergner wrote:
> I'd like to pull in Dan's upstream libffi commit into trunk to fix a
> wrong code bug/testsuite failure on powerpc64le-linux with long double
> defaulting to ieee128. This passed bootstrap and regtesting with no
> regressions. Ok for trunk?
>
> This bug
I'd like to pull in Dan's upstream libffi commit into trunk to fix a
wrong code bug/testsuite failure on powerpc64le-linux with long double
defaulting to ieee128. This passed bootstrap and regtesting with no
regressions. Ok for trunk?
This bug is also on the GCC 12 and GCC 11 release branches.
On 4/28/23 6:49 PM, Hans-Peter Nilsson wrote:
> On Fri, 28 Apr 2023, Jeff Law wrote:
>> So while what Ajit has done is a step forward, at some point the actual
>> details of the ABI need to be described in a way that can be checked and
>> consumed by REE.
>
> IIRC I also commented and suggested a
On 4/24/23 10:28 AM, Jakub Jelinek wrote:
> On Mon, Apr 24, 2023 at 10:23:06AM -0500, Peter Bergner wrote:
>> On 4/19/23 3:00 PM, Segher Boessenkool wrote:
>>> On Wed, Apr 19, 2023 at 11:23:07PM +0530, Ajit Agarwal wrote:
* common/config/rs6000/rs6000-common.cc: Add REE pass as a
On 4/19/23 3:00 PM, Segher Boessenkool wrote:
> On Wed, Apr 19, 2023 at 11:23:07PM +0530, Ajit Agarwal wrote:
>> * common/config/rs6000/rs6000-common.cc: Add REE pass as a
>> default rs6000 target pass for O2 and above.
>
> Why only for -O2? Only when optimising at all makes sense,
On 3/23/23 6:12 PM, Jeff Law via Gcc-patches wrote:
Is there a reason why REE cannot see that our (reg:QI 4) is a param
register
and thus due to our ABI, already correctly sign/zero extended?
>>>
>>> I don't think REE has ever considered exploiting ABI constraints. Handling
>>>
On 3/23/23 11:32 AM, Jeff Law via Gcc-patches wrote:
> On 3/23/23 10:29, Peter Bergner wrote:
>> I'm sorry that I don't know how REE works. Why can't it optimize this?
>> I see in the REE dump:
>>
>> (insn 20 18 22 3 (set (reg:DI 4 4)
>>(zero_extend:DI (reg:QI 4 4
On 3/23/23 8:47 AM, Jeff Law wrote:
> On 3/23/23 04:38, Ajit Agarwal wrote:
>> * ree.cc: Modification for AND opcode support to eliminate
>> unnecessary signed extension.
>> * testsuite/g++.target/powerpc/sext-elim.C: New tests.
> Just a note. I'll look at this once the trunk is open
On 3/23/23 5:38 AM, Ajit Agarwal wrote:
> This patch removed unnecessary signed extension elimination in ree pass.
> Bootstrapped and regtested on powerpc64-linux-gnu.
>
>
> Thanks & Regards
> Ajit
>
> rtl-optimization: ppc backend generates unnecessary signed extension.
>
>
On 3/19/23 10:20 PM, Kewen.Lin via Gcc-patches wrote:
> Nice, OK for trunk and gcc12 branch, thanks!
Pushed to trunk and the GCC 12 release branch. Thanks.
Peter
On 3/17/23 4:20 PM, Peter Bergner via Gcc-patches wrote:
> On 3/16/23 10:37 PM, Surya Kumari Jangala wrote:
>> The issue of suboptimal code exists even for integer return value and not
>> just bool return value. See
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784#c9
On 3/17/23 7:17 PM, Peter Bergner wrote:
> On 3/17/23 5:35 PM, Peter Bergner wrote:
>> When we expand the __builtin_vec_xst_trunc built-in, we use the wrong mode
>> for the MEM operand which causes an unrecognizable insn ICE. The solution
>> is to use the correct TMODE mode.
>>
>> Is this ok for
On 3/17/23 5:35 PM, Peter Bergner wrote:
> When we expand the __builtin_vec_xst_trunc built-in, we use the wrong mode
> for the MEM operand which causes an unrecognizable insn ICE. The solution
> is to use the correct TMODE mode.
>
> Is this ok for trunk and gcc12 assuming my bootstraps and
We ICE in combine_reload_insn if we've deleted the TO insn operand during
processing, because lra_get_insn_recog_data doesn't expect to see the note
that replaces the deleted insn. The solution here is to exit early if TO
is a debug insn or note.
This caused a bootstrap issue on
When we expand the __builtin_vec_xst_trunc built-in, we use the wrong mode
for the MEM operand which causes an unrecognizable insn ICE. The solution
is to use the correct TMODE mode.
Is this ok for trunk and gcc12 assuming my bootstraps and regtests show
no regressions?
Peter
gcc/
PR
On 3/16/23 10:37 PM, Surya Kumari Jangala wrote:
> The issue of suboptimal code exists even for integer return value and not
> just bool return value. See
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784#c9
> So the patch would need to take care of integer return values too.
Correct.
On 3/9/23 8:55 AM, Segher Boessenkool wrote:
> On Thu, Mar 09, 2023 at 05:30:53PM +0800, Kewen.Lin wrote:
>> on 2023/3/9 07:01, Peter Bergner via Gcc-patches wrote:
>>> This patch was tested in both GCC 11 and GCC 10 on powerpc64le-linux and
>>> showed no reg
PR109073 shows a problem where GCC 11 and GCC 10 do not accept a const
__vector_pair pointer operand to some MMA builtins, which GCC 12 and later
correctly accept. Fixed here by initializing the builtins to accept const
pointers.
This patch was tested in both GCC 11 and GCC 10 on
On 2/3/23 1:42 AM, Richard Biener wrote:
> On Fri, Feb 3, 2023 at 6:44 AM Michael Meissner via Gcc-patches
> wrote:
>>
>> I'm reposting these two patches that allow GCC to build on Fedora 36 just to
>> be
>> clear which patches I'm talking about. The issue is that if GCC is
>> configured
>>
On 2/6/23 1:25 AM, Richard Biener wrote:
> May I ask to consider delaying this to stage1 exactly because of this
> last reason?
That is our plan. We're just still working through the review so it's
ready when stage1 opens up.
Peter
On 11/9/22 8:44 PM, Michael Meissner via Gcc-patches wrote:
> + /* For now, make -mtune=future the same as -mtune=power10. */
> + if (rs6000_tune == PROCESSOR_FUTURE)
> +rs6000_tune = PROCESSOR_POWER10;
This comment matches the code...
> + /* Some future processor. For now, just use
On 9/9/22 8:47 PM, Segher Boessenkool wrote:
> On Fri, Sep 09, 2022 at 07:56:42PM -0500, Peter Bergner wrote:
>> On 9/9/22 8:27 AM, Kewen.Lin wrote:
>>> btw, it needs some hacking in rs6000_function_arg to make this
>>> opaque type valid for function arg.
>>
>> We don't allow (at this time)
On 9/9/22 8:27 AM, Kewen.Lin wrote:
> __attribute__((noipa))
> int foo(c){
> return 0;
> }
>
> int main ()
> {
> const __vector_quad c;
> int r = foo(c);
> return r;
> }
>
> Checking during LTO WPA, verify_type only gets type "const
> __vector_quad", no type "__vector_quad".
>
> btw, it
On 9/2/22 12:23 PM, Segher Boessenkool wrote:
> On Fri, Sep 02, 2022 at 12:02:54PM -0500, Peter Bergner wrote:
>> On 9/2/22 11:31 AM, Segher Boessenkool wrote:
>>> (Did you also look at non-MMA VIEW_CONVERT_EXPR uses btw?)
>>
>> I did. It seemed they were all related to pointers to vectors and I
On 9/2/22 11:31 AM, Segher Boessenkool wrote:
> I wouldn't worry about backports. If it does make other backports
> easier in the future, we can decide to backport this *then*.
Ok.
> (Did you also look at non-MMA VIEW_CONVERT_EXPR uses btw?)
I did. It seemed they were all related to
When we cast pointers to our opaque MMA pointers, use NOP_EXPR rather
than VIEW_CONVERT_EXPR.
This passed bootstrap and regtesting on powerpc64le-linux with no regressions.
Ok for trunk?
I think this is just a cleanup and not a correctness thing, so I'm assuming a
backport isn't needed? Or
On 9/1/22 4:52 PM, Segher Boessenkool wrote:
> On Thu, Sep 01, 2022 at 11:24:00AM +0800, Jiufu Guo wrote:
>> As mentioned in PR106550, since pli could support 34bits immediate, we could
>> use less instructions(3insn would be ok) to build 64bits constant with pli.
>
>> For example, for constant
On 9/1/22 3:29 AM, Kewen.Lin wrote:
>> I have no idea why ptr_vector_*_type would behave differently here than
>> build_pointer_type (vector_*_type_node). Using the build_pointer_type()
>> fixed it for me, so that's why I went with it. :-) Maybe this is a bug
>> in lto???
>
> Thanks for your
On 8/31/22 6:45 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 06:36:40PM -0500, Peter Bergner wrote:
>> Changes from v1:
>> * Fix spelling typo in git log entry
>> * Fix broken test checking src_ptr's type
>> * Use NOP_EXPR rather than VIEW_CONVERT_EXPR
>> * Change order of dg-options
>>
Changes from v1:
* Fix spelling typo in git log entry
* Fix broken test checking src_ptr's type
* Use NOP_EXPR rather than VIEW_CONVERT_EXPR
* Change order of dg-options
When we expand an MMA disassemble built-in with C++ using a pointer that
is cast to a valid MMA type, the type isn't passed
On 8/31/22 6:08 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 05:01:04PM -0500, Peter Bergner wrote:
>> The problem goes away if I use use -O1 or above, I drop -flto or I use
>> the code I originally posted without the ptr_vector_*_type
>>
>> The assert in
On 8/31/22 4:49 PM, Segher Boessenkool wrote:
> But it is incorrect as well. Instead, we should look if -mpowerpc64 is
> enabled explicitly, and not change it if so.
Sure, I agree with checking for explicit use. That said, I'll let
someone else work on this.
Peter
On 8/31/22 3:51 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 01:53:48PM -0500, Peter Bergner wrote:
>> Question for my own education, when would you use VIEW_CONVERT_EXPR over
>> NOP_EXPR?
>
> VIEW_CONVERT_EXPR is essentially a bit_cast. Only use it when you need
> that, it is
On 8/31/22 4:07 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 02:53:07PM -0500, Peter Bergner wrote:
>> Changing OS_MISSING_POWERPC64 as I mentioned would not add
>> OPTION_MASK_POWERPC64
>> to our cpu masks when -m32 is used.
>
> So you say this is where the bug is?
For linux64.h
On 8/31/22 2:28 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 12:00:14PM -0500, Peter Bergner wrote:
> No. Instead, it just works!
>
> Try this:
> ===
> typedef float vf __attribute__((vector_size(16)));
> vf f(float x)
> {
> x *= 42;
> return (vf){x, x, x, x};
> }
> ===
>
On 8/31/22 8:59 AM, Peter Bergner wrote:
> On 8/31/22 4:22 AM, Kewen.Lin wrote:
>> on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote:
>>> - tree src_type = TREE_TYPE (src_ptr);
>>> + tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
>>> +
On 8/31/22 11:05 AM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 10:48:26AM -0500, Peter Bergner wrote:
>> Ditto for -msoft-float better disable any -maltivec and -mvsx, etc.
>
> Oh? Why should it disable -maltivec? -mvsx makes a little sense on
> one hand, but totally none on the other
On 8/31/22 10:24 AM, Segher Boessenkool wrote:
> Should *any* explicit command line flag ever be disabled like that?
> (Not talking about things like -m32 -m64, ...
In a general sense, I'd agree that the answer is no, but we do have
dependent options like -maltivec and -mvsx, etc., so a
On 8/31/22 4:33 AM, Kewen.Lin via Gcc-patches wrote:
> Commit r12-2266 updated the scanned assembly content from
>
> "{\mlvx\M|\mlxv\M|\mlxvd2x\M}"
>
> to
>
> "{\mp?lxv\M|\mlxv\M|\mlxvd2x\M}"
>
> for the test case pr86731-fwrapv-longlong.c unexpectedly.
>
> It's meant to update "lxv" to
On 8/31/22 4:33 AM, Kewen.Lin wrote:
> @@ -1,7 +1,8 @@
> /* { dg-do compile { target { powerpc*-*-* } } } */
> /* { dg-skip-if "" { powerpc*-*-aix* } } */
> -/* { dg-options "-O2 -mpowerpc64" } */
> /* { dg-require-effective-target ilp32 } */
> +/* { dg-options "-O2 -mpowerpc64" } */
> +/* {
On 8/31/22 4:22 AM, Kewen.Lin wrote:
> on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote:
>> - tree src_type = TREE_TYPE (src_ptr);
>> + tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
>> + ? build_pointer_type (
I'd like to ping the following patch.
Peter
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600451.html
Message-ID:
>When we expand an MMA disassemble built-in with C++ using a pointer that
>is casted to a valid MMA type, the type isn't passed down to the expand
>machinery and we
On 8/27/22 7:47 PM, Peter Bergner via Gcc-patches wrote:
> On 8/27/22 4:37 PM, Segher Boessenkool wrote:
>>> The fix is to just remove the MMA pointer conversion
>>> handling code altogether.
>>
>> Okay for trunk and all backports. Thanks!
>
> Ok, pushed t
On 8/27/22 4:37 PM, Segher Boessenkool wrote:
> Such conversions are explicitly allowed in C, even (6.3.2.3/7).
Yeah, I think I just got a little carried away disabling them originally. :-(
>> The fix is to just remove the MMA pointer conversion
>> handling code altogether.
>
> Okay for trunk
GCC incorrectly disables conversions between MMA pointer types, which
are allowed with clang. The original intent was to disable conversions
between MMA types and other other types, but pointer conversions should
have been allowed. The fix is to just remove the MMA pointer conversion
handling
When we expand an MMA disassemble built-in with C++ using a pointer that
is casted to a valid MMA type, the type isn't passed down to the expand
machinery and we end up using the base type of the pointer which leads to
an ICE. This patch enforces we always use the correct MMA type regardless
of
On 8/23/22 6:49 AM, Surya Kumari Jangala wrote:
> sched1: Fix -fcompare-debug issue in schedule_region [PR105586]
>
> In schedule_region(), a basic block that does not contain any real insns
> is not scheduled and the dfa state at the entry of the bb is not copied
> to the fallthru basic block.
On 7/26/22 1:57 AM, Richard Biener via Gcc-patches wrote:
>> On 6/17/22 11:50 PM, Peter Bergner via Gcc-patches wrote:
>>> The initial commit that added opaque types thought that there couldn't
>>> be any valid initializations for variables of these types, but the test
&g
Handle initializations of opaque types [PR106016]
On 6/17/22 11:50 PM, Peter Bergner via Gcc-patches wrote:
> The initial commit that added opaque types thought that there couldn't
> be any valid initializations for variables of these types, but the test
> case in the bug report shows that isn't true
On 7/22/22 1:53 PM, Peter Bergner wrote:
> So I think the way the code above *should* work is:
> 1) Any -mdejagnu-cpu= usage should filter out all -mcpu= and -mtune=
> options.
> 2) Any -mdejagnu-tune= usage should filter all -mtune= options.
> It should not filter out any -mcpu=
On 7/22/22 1:17 PM, Segher Boessenkool wrote:
> On Fri, Jul 22, 2022 at 10:22:51AM +0800, Kewen.Lin wrote:
>> on 2022/7/22 02:48, Segher Boessenkool wrote:
>> As PR106345 shows, GCC can use an explicit tune setting when it's
>> configured, even if there is one "-mdejagnu-cpu=", it doesn't
>>
The initial commit that added opaque types thought that there couldn't
be any valid initializations for variables of these types, but the test
case in the bug report shows that isn't true. The solution is to handle
OPAQUE_TYPE initializations just like the other scalar types.
This passed
On 6/7/22 10:16 PM, Michael Meissner wrote:
> Otherwise it is like the mess with -mpower8-fusion, where going from power8 to
> power9 we have to clear the fusion flag. If store vector pair is a postive
> flag, then it isn't set in power10 flags, but it might be set in next cpu
> flags. But if it
On 6/7/22 4:24 PM, Segher Boessenkool wrote:
> On Tue, Jun 07, 2022 at 04:17:04PM -0500, Peter Bergner wrote:
>> I think I mentioned this offline, but I'd prefer a negative target flag,
>> something like TARGET_NO_STORE_VECTOR_PAIR that defaults to off, meaning we'd
>> generate stxvp by default.
>
On 6/6/22 7:55 PM, Michael Meissner wrote:
> gcc/
[snip]
> * config/rs6000/rs6000.opt (-mstore-vector-pair): New option.
[snip]
> diff --git a/gcc/config/rs6000/rs6000.opt b/gcc/config/rs6000/rs6000.opt
> index 4931d781c4e..79ceec6e6a5 100644
> --- a/gcc/config/rs6000/rs6000.opt
> +++
On 5/17/22 6:41 PM, Segher Boessenkool wrote:
> On Mon, May 16, 2022 at 05:31:31PM -0500, Peter Bergner wrote:
>> (define_insn "mma_"
>> - [(set (match_operand:XO 0 "fpr_reg_operand" "=")
>> -(unspec:XO [(match_operand:V16QI 1 "vsx_register_operand" "wa")
>> -
On 5/10/22 5:35 PM, Segher Boessenkool wrote:
> Out of interest, did you try using v,?wa (so just two alternatives, not
> four)? Or did you think it wouldresult in measurably worse code? Or
> did you decide it is not such bad backend code size explosion after
> all :-)
So I tried using just
On 5/10/22 5:46 PM, Peter Bergner wrote:
>> Out of interest, did you try using v,?wa (so just two alternatives, not
>> four)? Or did you think it wouldresult in measurably worse code? Or
>> did you decide it is not such bad backend code size explosion after
>> all :-)
>
> I have not tried
On 5/10/22 5:35 PM, Segher Boessenkool wrote:
> If you want to use this same message as commit message, you shouldn't
> say "this patch". Also, try not to use lines more than 72 positions
> wide (which handily is also a good maximum length for email messages,
> that way it can be quoted a few
This patch addresses an issue when compiling the MMA optimized DGEMM kernel
in OpenBLAS. The MMA code uses all 8 accumulators, which overlap all vs0-vs31
vector registers. Current trunk assigns one of the normal vector inputs to
one of the MMA instructions, which forces us to spill one of the
On 5/5/22 4:27 PM, Segher Boessenkool wrote:
> On Thu, May 05, 2022 at 02:59:07PM -0500, Peter Bergner wrote:
>> On 5/5/22 2:35 PM, Segher Boessenkool wrote:
>>> Just an unconditional
>>>
>>> callee_isa &= ~OPTION_MASK_P8_FUSION;
>>> explicit_isa &= ~OPTION_MASK_P8_FUSION;
>>>
>>> will do, no?
On 5/5/22 5:51 PM, Michael Meissner wrote:
> On Thu, May 05, 2022 at 02:35:34PM -0500, Segher Boessenkool wrote>> A patch
> like that is pre-approved, even for trunk.
>
> And as I said, logically we should do the same for p10 fusion. I.e.
>
>callee_isa &= ~(OPTION_MASK_P8_FUSION
>
On 5/5/22 4:27 PM, Segher Boessenkool wrote:
> On Thu, May 05, 2022 at 02:59:07PM -0500, Peter Bergner wrote:
>> On 5/5/22 2:35 PM, Segher Boessenkool wrote:
>>> A patch like that is pre-approved, even for trunk.
>>
>> That works for me! I will apply this directly to GCC 10 and regtest and
>>
On 5/5/22 2:35 PM, Segher Boessenkool wrote:
> On Thu, May 05, 2022 at 01:59:05PM -0500, Peter Bergner wrote:
>> If we cannot get this in soonish, maybe we can at least get approval for
>> applying Mike's simpler patch to the release branches, specifically GCC 10?
>>
>>
1 - 100 of 298 matches
Mail list logo
