Hi hao Chen,
On Wed, Sep 09, 2020 at 04:55:29PM +0800, HAO CHEN GUI wrote:
> Thanks for your advice. I removed macros defined in linux64.h and
> linux.h. So they take relative jump tables by default. When
> no-relative-jumptables is set, the absolute jump tables are taken. All
> things rele
Hi!
[ Please CC: me on rs6000 patches. Thanks! ]
On Tue, Sep 29, 2020 at 12:26:28PM +0200, Eric Botcazou wrote:
> and the masking is present all the way down to the assembly at -O2:
>
> rlwinm 4,4,0,27,31
> rotlw 3,3,4
>
> Now this masking is redundant since it's done by the ha
On Tue, Sep 29, 2020 at 11:36:12AM +0100, Alex Coplan wrote:
> Is the combine change (a canonicalization fix, as described below) OK
> for trunk in light of this info?
Can you please resend it with correct info and a corresponding commit
message?
Segher
Hi Raoni,
Some of this isn't an rs6000 patch, but the subject says it is, so it
might well not draw the attention it needs.
Adding some Cc:s.
On Fri, Sep 04, 2020 at 12:52:30PM -0300, Raoni Fassina Firmino wrote:
> There is one pending question raised by Segher, It is about adding
> documentatio
We have too many tablejump patterns. Using parameterized names
simplifies the code a bit.
Tested on powerpc64-linux {-m32,-m64}. Committing.
Segher
2020-09-29 Segher Boessenkool
* config/rs6000/rs6000.md (tablejump): Simplify.
(tablejumpsi): Merge this
On Wed, Sep 30, 2020 at 09:02:34AM +0200, Richard Biener wrote:
> On Tue, 29 Sep 2020, Segher Boessenkool wrote:
> > I don't see much about optabs in the docs either. Add some text to
> > optabs.def itself then?
>
> All optabs are documented in doc/md.texi as 'in
Hi!
On Wed, Sep 30, 2020 at 05:01:45PM +0930, Alan Modra wrote:
> * config/rs6000/linux64.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Don't
> set -mcmodel=small for -mno-minimal-toc when pcrel.
> - SET_CMODEL (CMODEL_SMALL);\
> + if (TARGET_MINIMAL_T
On Wed, Sep 30, 2020 at 05:06:57PM +0930, Alan Modra wrote:
> Generate assembly that is .localentry 1 with @notoc calls to match.
What is the purpose of this? Non-obvious patchexs without any
explanation like that cost needless extra time to review :-/
"Support __PCREL__ code." suggests that it
Hi Alan,
On Thu, Oct 01, 2020 at 08:49:44AM +0930, Alan Modra wrote:
> On Wed, Sep 30, 2020 at 05:36:08PM -0500, Segher Boessenkool wrote:
> > On Wed, Sep 30, 2020 at 05:06:57PM +0930, Alan Modra wrote:
> > > Generate assembly that is .localentry 1 with @notoc calls to match.
&g
Hi!
On Thu, Oct 01, 2020 at 10:57:48PM +0930, Alan Modra wrote:
> On Wed, Sep 30, 2020 at 03:56:32PM -0500, Segher Boessenkool wrote:
> > On Wed, Sep 30, 2020 at 05:01:45PM +0930, Alan Modra wrote:
> > > * config/rs6000/linux64.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Don't
>
On Thu, Oct 01, 2020 at 08:59:12PM +0200, Martin Liška wrote:
> Since a889e06ac68 the following fails.
>
> In file included from ../../gcc/tree-ssa-propagate.h:25:0,
> from ../../gcc/config/rs6000/rs6000.c:78:
> ../../gcc/value-query.h:90:31: error: ‘irange’ has not been declared
On Thu, Oct 01, 2020 at 08:08:01AM +0200, Richard Biener wrote:
> On Wed, 30 Sep 2020, Segher Boessenkool wrote:
>
> > On Wed, Sep 30, 2020 at 09:02:34AM +0200, Richard Biener wrote:
> > > On Tue, 29 Sep 2020, Segher Boessenkool wrote:
> > > > I don't se
Hi Alan,
On Fri, Oct 02, 2020 at 07:06:46AM +0930, Alan Modra wrote:
> > > I was looking at it again today
> > > with the aim of converting this ugly macro to a function, and spotted
> > > the duplication in freebsd64.h. Which has some bit-rot.
> > >
> > > Do you like the following? rs6000_linu
Hi!
On Thu, Oct 01, 2020 at 11:03:37PM +0930, Alan Modra wrote:
> during RTL pass: fwprop1
> gcc.dg/pr82596.c: In function 'test_cststring':
> gcc.dg/pr82596.c:27:1: internal compiler error: in decompose, at rtl.h:2282
>
> -m32 gcc/testsuite/gcc.dg/pr82596.c fails along with other tests after
> a
On Fri, Oct 02, 2020 at 10:46:12AM +0200, Aldy Hernandez wrote:
> On 10/2/20 2:17 AM, David Edelsohn wrote:
> >On Thu, Oct 1, 2020 at 8:02 PM Andrew MacLeod wrote:
> >Thanks for investigating. And I definitely am not suggesting that you
> >delay the great progress on Ranger to flatten and compact
Hi Eric,
On Fri, Oct 02, 2020 at 10:26:24AM +0200, Eric Botcazou wrote:
> > Don't call it "mask" please: *all* of our basic rotate instructions
> > already have something called "mask" (that is the "m" in "rlwnm" for
> > example; and "rotlw d,a,b" is just an extended mnemonic for
> > "rlwnm d,a,b,
Hi!
On Fri, Oct 02, 2020 at 04:41:05PM +0930, Alan Modra wrote:
> This moves an #ifdef block of code from calls.c to
> targetm.function_ok_for_sibcall. Only two targets, x86 and rs6000,
> define REG_PARM_STACK_SPACE or OUTGOING_REG_PARM_STACK_SPACE macros
> that might vary depending on the called
Hi Olivier,
On Thu, Oct 01, 2020 at 11:30:55AM +0200, Olivier Hainque wrote:
> This change reworks CPP_BUILTINS_SPEC for powerpc-vxworks to
> prepare for the upcoming addition of 32 and 64 bit ports for
> VxWorks 7r2.
Cool, looking forward to it!
Your attachment is not quotable (it is applicatio
On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches wrote:
> On Linux/x86_64,
>
> c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit
> commit c34db4b6f8a5d80367c709309f9b00cb32630054
> Author: Jan Hubicka
> Date: Sat Oct 3 17:20:16 2020 +0200
>
> Track ac
Hi!
On Sun, Oct 04, 2020 at 11:09:11PM +1030, Alan Modra wrote:
> On Fri, Oct 02, 2020 at 01:50:24PM -0500, Segher Boessenkool wrote:
> > > + /* If reg parm stack space increases, we cannot sibcall. */
> > > + if (REG_PARM_STACK_SPACE (decl ? decl : fntype)
> > >
On Sun, Oct 04, 2020 at 09:51:23AM -0700, H.J. Lu wrote:
> On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
> wrote:
> > On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches
> > wrote:
> > > On Linux/x86_64,
> > >
> > > c34db4b6
Hi!
On Sun, Oct 04, 2020 at 09:56:01PM -0400, Hans-Peter Nilsson wrote:
> Please excuse a comment from the gallery:
>
> On Mon, 28 Sep 2020, will schmidt via Gcc-patches wrote:
> > On Fri, 2020-09-04 at 12:52 -0300, Raoni Fassina Firmino via Gcc-patches
> > wrote:
> > > +(define_expand "feraisee
Hi!
On Wed, Aug 19, 2020 at 04:03:31PM -0300, Tulio Magno Quites Machado Filho via
Gcc-patches wrote:
> Replace them with a whitespace in order to avoid artifacts in the HTML
> document.
Multiple whitespaces in texinfo are supposed to work correctly, and are
good to have for various reasons (mor
Hi!
On Wed, Oct 07, 2020 at 12:44:04PM -0500, will schmidt wrote:
> Rename our BU_P10_MISC_2 built-in define macro to be
> BU_P10_POWERPC64_MISC_2. This more accurately reflects
> that the macro includes the RS6000_BTM_POWERPC64 entry
> that is not present in the other BU_P10_MISC macros,
> a
On Thu, Oct 08, 2020 at 11:21:26AM +0100, Alex Coplan wrote:
> Ping. The kernel is still broken on AArch64.
You *cannot* fix a correctness bug with a combine addition. So please
fix the target bug first.
I haven't had time to look at your patch yet, sorry.
Segher
On Fri, Oct 09, 2020 at 09:38:09AM +0100, Alex Coplan wrote:
> Hi Segher,
>
> On 08/10/2020 15:20, Segher Boessenkool wrote:
> > On Thu, Oct 08, 2020 at 11:21:26AM +0100, Alex Coplan wrote:
> > > Ping. The kernel is still broken on AArch64.
> >
> > You *
Hi!
On Mon, Sep 19, 2022 at 06:19:15PM -0500, will schmidt wrote:
> This is the first of a batch of changes that eliminate a number
> of define TARGET_foo entries we have collected over time.
Good good :-)
> TARGET_CTZ is defined as TARGET_MODULO, and has a low number
> of uses. References to
On Tue, Sep 20, 2022 at 05:01:53PM -0500, will schmidt wrote:
> On Tue, 2022-09-20 at 16:14 -0500, Segher Boessenkool wrote:
> > > TARGET_FCTIWUZ has a low number of uses, and can be directly
> > > replaced with TARGET_POPCNTD.
> >
> > It is a p7 (ISA 2.06) insn.
Hi!
On Fri, Jun 24, 2022 at 10:02:19AM +0800, HAO CHEN GUI wrote:
> This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead
> of smin/max. So the builtins always generate xs[min/max]dp on all
> platforms.
But how does this not blow up with -ffast-math?
In the other direction I am
Hi!
On Thu, Sep 22, 2022 at 05:59:07PM +0800, HAO CHEN GUI wrote:
> >> I still think we should get RTL codes for this, to have access to proper
> >> floating point min/max semantics always and everywhere. "fmin" and
> >> "fmax" seem to be good names :-)
> >
> > It would be good, especially if we
Hi!
On Thu, Sep 22, 2022 at 10:28:23AM +0800, Kewen.Lin wrote:
> on 2022/9/22 05:56, Segher Boessenkool wrote:
> > On Fri, Jun 24, 2022 at 10:02:19AM +0800, HAO CHEN GUI wrote:
> > In the other direction I am worried that the unspecs will degrade
> > performance (relati
Hi!
Heh, I first thought I had mistyped thgew PR #, but it is this one after
all :-)
On Thu, Sep 22, 2022 at 09:41:34AM +0800, Kewen.Lin wrote:
> PR100645 exposes one latent bug in define_expand vec_shr_
> that the current condition TARGET_ALTIVEC is too loose. The
> mode iterator VEC_L contains
Hi!
On Thu, Sep 22, 2022 at 09:41:42AM +0800, Kewen.Lin wrote:
> * config/rs6000/rs6000-logue.cc (rs6000_emit_epilogue): Update the
> condition for adding REG_CFA_DEF_CFA reg note with
> frame_pointer_needed_indeed.
> --- a/gcc/config/rs6000/rs6000-logue.cc
> +++ b/gcc/config/rs
Hi!
On Wed, Aug 24, 2022 at 04:17:55PM +0800, Kewen.Lin wrote:
> As PR106516 shows, we can get unexpected gimple outputs for
> function thud on some target which supports modulus operation
> for vector int. This patch introduces one effective target
> vect_int_mod for it, then adjusts the test ca
On Wed, Sep 28, 2022 at 01:35:09PM +0800, Kewen.Lin wrote:
> I assumed the generic part introducing check_effective_target_vect_int_mod
> needs the approval from global maintainers.
Target-specific testsuite changes can be approved by target maintainers.
Currently this can be considered target-spe
Hi!
On Thu, Aug 25, 2022 at 01:50:28PM +0800, Kewen.Lin wrote:
> --- a/gcc/config/rs6000/rs6000-internal.h
> +++ b/gcc/config/rs6000/rs6000-internal.h
> @@ -183,10 +183,15 @@ extern tree rs6000_fold_builtin (tree fndecl
> ATTRIBUTE_UNUSED,
>tree *args ATTRIBUTE_UNU
Hi!
On Wed, Sep 28, 2022 at 05:18:47PM +0100, Iain Sandoe wrote:
> > On 28 Sep 2022, at 07:37, Iain Sandoe wrote:
> >> On 28 Sep 2022, at 06:30, Kewen.Lin via Gcc-patches
> >> wrote:
> >> PR106680 shows that -m32 -mpowerpc64 is different from
> >> -mpowerpc64 -m32, this is determined by the way
On Wed, Sep 28, 2022 at 01:30:46PM +0800, Kewen.Lin wrote:
> PR106680 shows that -m32 -mpowerpc64 is different from
> -mpowerpc64 -m32, this is determined by the way how we
> handle option powerpc64 in rs6000_handle_option.
>
> Segher pointed out this difference should be taken as
> a bug and we s
Hi!
On Thu, Sep 29, 2022 at 09:16:33AM +0100, Iain Sandoe wrote:
> OK. So one small wrinkle,
>
> Darwin already has
>
> if (TARGET_64BIT && ! TARGET_POWERPC64)
> {
> rs6000_isa_flags |= OPTION_MASK_POWERPC64;
> warning (0, "%qs requires PowerPC64 architecture, enabling", "-m6
On Thu, Sep 29, 2022 at 01:45:16PM +0800, Kewen.Lin wrote:
> I found this flag is mainly related to tune setting and spotted that we have
> some code
> for tune setting when no explicit cpu is given.
>
> ...
>
> else
> {
> size_t i;
> enum processor_type tune_proc
> = (T
On Thu, Sep 29, 2022 at 12:04:05AM +0100, Iain Sandoe wrote:
> > On 28 Sep 2022, at 22:30, Segher Boessenkool
> > wrote:
> > That works on Linux as well. What still does not work is user-mode
> > context switches in 32-bit processes (so setjmp and getcontext stuff).
&g
On Thu, Sep 29, 2022 at 12:16:38AM +0100, Iain Sandoe wrote:
> > On 29 Sep 2022, at 00:04, Iain Sandoe wrote:
> > adding —with-tune=G5 to the configure line .. the cross-build then succeeded
> > (at "-O1 -g" as I was building to debug) - maybe that will provide a clue,
> > but I’m
> > out of time
Hi!
On Thu, Sep 29, 2022 at 07:25:44PM +0100, Iain Sandoe wrote:
> > On 29 Sep 2022, at 18:04, Segher Boessenkool
> > wrote:
> > On Thu, Sep 29, 2022 at 09:16:33AM +0100, Iain Sandoe wrote:
> >> Which means that we do not report an error, but a warning, and then we
On Thu, Sep 29, 2022 at 07:33:14PM +0100, Iain Sandoe wrote:
> > On 29 Sep 2022, at 18:18, Segher Boessenkool
> > wrote:
> > On Thu, Sep 29, 2022 at 12:04:05AM +0100, Iain Sandoe wrote:
> >>> On 28 Sep 2022, at 22:30, Segher Boessenkool
> >>> wrote
Hi!
On Thu, Sep 29, 2022 at 02:16:04PM +0800, Kewen.Lin wrote:
> >> +/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target
> >> powerpc*-*-linux* powerpc-*-rtems* } 0 } */
> >
> > Everything except AIX even? So it will include Darwin as well (and the
> > BSDs, and powerpc*-elf, et
Hi!
On Wed, Aug 24, 2022 at 04:17:07PM +0800, Kewen.Lin wrote:
> --- a/gcc/config/rs6000/rs6000.cc
> +++ b/gcc/config/rs6000/rs6000.cc
> @@ -14771,18 +14771,9 @@ rs6000_print_patchable_function_entry (FILE *file,
> unsigned HOST_WIDE_INT patch_area_size,
>
Hi!
On Thu, Sep 29, 2022 at 12:01:43PM +0200, Jakub Jelinek via Gcc-patches wrote:
> --- gcc/config/i386/i386.cc.jj2022-09-29 09:13:25.713718513 +0200
> +++ gcc/config/i386/i386.cc 2022-09-29 11:29:20.828358152 +0200
> @@ -22725,6 +22725,9 @@ ix86_mangle_type (const_tree type)
>&
On Fri, Sep 30, 2022 at 05:31:26PM +0200, Jakub Jelinek wrote:
> On Fri, Sep 30, 2022 at 10:07:59AM -0500, Segher Boessenkool wrote:
> > On Thu, Sep 29, 2022 at 12:01:43PM +0200, Jakub Jelinek via Gcc-patches
> > wrote:
> > > --- gcc/config/i386/i386.cc.jj2022-09-29
On Fri, Sep 30, 2022 at 08:47:53PM +0800, Kewen.Lin wrote:
> on 2022/9/30 04:31, Segher Boessenkool wrote:
> > Please don't define TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY at all,
> > instead, and remove this whole function?
>
> This hook is still needed for "EL
Hi!
On Fri, Sep 23, 2022 at 11:49:24AM -0400, Olivier Hainque wrote:
> For a powerpc compiler configured with --with-abi=elfv2, an explicit
> -mabi option other than elfv1 fails to override the default.
>
> For example, after
>
> [...]/configure --enable-languages=c --target=powerpc-elf --with
On Fri, Sep 30, 2022 at 08:15:37PM +0800, Kewen.Lin wrote:
> on 2022/9/30 01:11, Segher Boessenkool wrote:
> >> +#ifdef OS_MISSING_POWERPC64
> >> + else if (OS_MISSING_POWERPC64)
> >> + /* It's unexpected to have OPTION_MASK_POWERPC64 on for OSes which
&g
ortly.
Segher
Segher Boessenkool (3):
rs6000: Remove "wD" from *vsx_extract__store
rs6000: Rework vsx_extract_
rs6000: Remove the wD constraint
gcc/config/rs6000/constraints.md | 6 ---
gcc/config/rs6000/vsx.md | 85 +++-
is, cost 0, making it more likely RA will choose it.
2022-10-05 Segher Boessenkool
* config/rs6000/vsx.md (vsx_extract_): Replace define_insn by a
define_expand. Split the contents to...
(*vsx_extract__0): ... this. Rewrite.
(*vsx_extract__01: ... and this
We can use "n" instead of "wD" if we simply test the value of the
integer constant directly.
2022-10-05 Segher Boessenkool
* config/rs6000/vsx.md (*vsx_extract__store): Use "n" instead of
"wD" constraint.
---
gcc/config/rs6000/vsx.md
2022-10-05 Segher Boessenkool
* config/rs6000/constraints.md (wD): Delete.
* doc/md.texi (Machine Constraints): Adjust.
---
gcc/config/rs6000/constraints.md | 6 --
gcc/doc/md.texi | 3 ---
2 files changed, 9 deletions(-)
diff --git a/gcc/config/rs6000
Hi!
On Thu, Oct 06, 2022 at 04:29:57PM -0500, will schmidt wrote:
> As reported in PR 100693, attempts to use __builtin_addg6s
> with long long arguments result in truncated results.
>
> Since the int and long long types can be coerced into each other,
> (documented further near the rs6000-c.cc
On Mon, Oct 10, 2022 at 10:15:58AM +0800, Kewen.Lin wrote:
> on 2022/10/4 05:15, Segher Boessenkool wrote:
> > Right. If If mpowerpc64 is enabled while OS_MISSING_POWERPC64, warn for
> > that;
>
> Currently if option powerpc64 is enabled explicitly while
> OS_MISSING_
On Tue, Mar 01, 2022 at 10:28:57PM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> > No. insn_cost is only for correct, existing instructions, not for
> > made-up nonsense. I created insn_cost precisely to get away from that
> > aspect of rtx_cost (and some othe
On Wed, Mar 02, 2022 at 03:54:29PM -0500, Michael Meissner wrote:
> Optimize signed DImode -> TImode on power10.
> On power10, GCC tries to optimize the signed conversion from DImode to
> TImode by using the vextsd2q instruction. However to generate this
> instruction, it would have to generate 3
Hi!
On Mon, Feb 21, 2022 at 12:37:56AM +0100, pku...@freebsd.org wrote:
> From: Piotr Kubaj
>
> While FreeBSD currently uses 64-bit long double, there should be no
> problem with adding support for float128.
>
> Signed-off-by: Piotr Kubaj
This needs a changelog. The entry for configure shoul
}. Also manually tested with all
-mcpu=, and the output of that passed through the GNU assembler.
I plan to commit this later today.
Segher
2022-03-04 Segher Boessenkool
* config/rs6000/rs6000.c (rs6000_machine_from_flags): Restructure a bit.
Handle most older CPUs.
---
gcc
Hi!
On Sat, Mar 05, 2022 at 09:21:51AM +0100, Jakub Jelinek wrote:
> As mentioned in the PR, right now on powerpc* __SIZEOF_{FLOAT,IBM}128__
> macros are predefined unconditionally, because {ieee,ibm}128_float_type_node
> is always non-NULL, doesn't reflect whether __ieee128 or __ibm128 are
> actu
On Mon, Mar 07, 2022 at 08:53:42PM +, Joseph Myers wrote:
> This breaks the build of libgcc for powerpc-linux-gnu (32-bit, default
> CPU; configured --disable-multilib --enable-secureplt).
>
> cc1: warning: The '-mfloat128' option may not be fully supported
> /tmp/ccHCPzSh.s: Assembler messag
On Mon, Mar 07, 2022 at 07:03:17PM -0500, Marek Polacek via Gcc-patches wrote:
> In r270550, Jakub fixed classify_insn to handle asm goto: if the asm can
> jump to a label, the insn should be a JUMP_INSN.
>
> However, as the following testcase shows, non-null ASM_OPERANDS_LABEL_VEC
> doesn't guara
Hi!
On Tue, Mar 08, 2022 at 10:08:25AM -0500, Marek Polacek wrote:
> On Mon, Mar 07, 2022 at 07:19:09PM -0600, Segher Boessenkool wrote:
> > On Mon, Mar 07, 2022 at 07:03:17PM -0500, Marek Polacek via Gcc-patches
> > wrote:
> > > In r270550, Jakub fixed classify_insn to
On Tue, Mar 08, 2022 at 10:25:45AM -0500, Marek Polacek wrote:
> On Tue, Mar 08, 2022 at 09:14:56AM -0600, Segher Boessenkool wrote:
> > On Tue, Mar 08, 2022 at 10:08:25AM -0500, Marek Polacek wrote:
> > > ...I don't see that. In fact copy_rtx does the same t
On Tue, Mar 08, 2022 at 05:12:43PM +0100, Jakub Jelinek wrote:
> On Tue, Mar 08, 2022 at 09:49:15AM -0600, Segher Boessenkool wrote:
> > > But like I said above, even if we didn't copy these XVECLEN 0 rtvecs,
> > > the crash would not go away.
> >
> > An rtve
On Fri, Feb 11, 2022 at 12:53:07PM -0500, Michael Meissner wrote:
> Ping patch for PR target/102059 to ignore implicit -mpower8-fusion that
> prevents a function targeting power9 or power10 from inlining a function that
> declared it needed power8 via attribute/pragma target.
Can we just disable a
Hi!
On Wed, Mar 09, 2022 at 02:27:19PM +0100, Jakub Jelinek wrote:
> On Mon, Mar 07, 2022 at 03:37:18PM -0600, Segher Boessenkool wrote:
> > > 2) adjusts the builtins code to use
> > >ibm128_float_type_node ? ibm128_float_type_node : long_double_type_node
> > >
On Wed, Mar 09, 2022 at 08:24:24PM +0100, Jakub Jelinek wrote:
> On Wed, Mar 09, 2022 at 12:34:06PM -0600, Segher Boessenkool wrote:
> > > rs6000_expand_builtin has (but at an incorrect spot) code to remap
> > > __builtin_{,un}pack_ibm128 to __builtin_{,un}pack_longdouble
On Wed, Mar 09, 2022 at 10:10:07PM +0100, Jakub Jelinek wrote:
> On Wed, Mar 09, 2022 at 02:57:20PM -0600, Segher Boessenkool wrote:
> > But __ibm128 should *always* be supported, so this is a hypothetical
> > problem.
>
> I bet that will require much more work. I think for
Hi!
On Thu, Mar 10, 2022 at 09:25:21AM +0100, Sebastian Huber wrote:
> On 04/03/2022 17:51, Segher Boessenkool wrote:
> >This adds more correct .machine for most older CPUs. It should be
> >conservative in the sense that everything we handled before we handle at
> >least as
Hi!
On Thu, Mar 10, 2022 at 10:35:36AM +0100, Jakub Jelinek wrote:
> On Wed, Mar 09, 2022 at 04:57:01PM -0600, Segher Boessenkool wrote:
> > > > If you are fed up with all this, please commit what you have now (after
> > > > testing of course ;-) ), and I'll pi
On Thu, Mar 10, 2022 at 10:44:52AM -0600, will schmidt wrote:
> On Wed, 2022-03-09 at 22:49 -0500, Michael Meissner wrote:
> > --- a/gcc/config/rs6000/rs6000-cpus.def
> > +++ b/gcc/config/rs6000/rs6000-cpus.def
> > @@ -43,9 +43,7 @@
> > | OPTION_MASK_ALTIVEC
Hi!
On Thu, Mar 10, 2022 at 09:54:55AM -0800, Patrick O'Neill wrote:
> I added this enforcement during the combine pass since it looks at the
> cost of certian expressions and can rely on the target to tell the
> pass that clobber-ops are cheaper than regular ops.
That is not a reason to put targ
On Fri, Mar 11, 2022 at 01:07:29AM -0500, Michael Meissner wrote:
> Fix DImode to TImode sign extend issue, PR target/104898
> When I wrote the extendditi2 pattern, I forgot that mtvsrdd had that
> behavior so I used a 'r' constraint instead of 'b'. In the rare case
> where the value is in GPR re
On Fri, Mar 11, 2022 at 08:42:27PM +, Joseph Myers wrote:
> The version of this patch applied to GCC 10 branch (commit
> 641b407763ecfee5d4ac86d8ffe9eb1eeea5fd10) has broken the glibc build for
> powerpc64le-linux-gnu (it's fine with GCC 11 branch and master, just GCC
> 10 branch is broken)
On Fri, Mar 11, 2022 at 09:57:50PM +0100, Jakub Jelinek wrote:
> On Fri, Mar 11, 2022 at 02:51:23PM -0600, Segher Boessenkool wrote:
> > On Fri, Mar 11, 2022 at 08:42:27PM +, Joseph Myers wrote:
> > > The version of this patch applied to GCC
good idea (even if the errors are actually
pre-existing: using -mvsx with a machine that does not have VXX cannot
work properly).
Will commit later today (if it regstraps fine :-) )
Segher
2022-03-11 Segher Boessenkool
PR target/104829
* config/rs6000/rs6000.cc
On Fri, Mar 11, 2022 at 05:51:05PM -0500, Michael Meissner wrote:
> On Fri, Mar 11, 2022 at 02:51:23PM -0600, Segher Boessenkool wrote:
> > On Fri, Mar 11, 2022 at 08:42:27PM +, Joseph Myers wrote:
> > > The version of this patch applied to GCC
Hi!
On Tue, Mar 15, 2022 at 03:29:23PM +0100, Sebastian Huber wrote:
> now that the PR104829 is fixed could I back port
>
> Segher Boessenkool (2):
> rs6000: Improve .machine
> rs6000: Do not use rs6000_cpu for .machine ppc and ppc64 (PR104829)
>
> to GCC 10 and 11?
I
On Tue, Mar 15, 2022 at 02:49:39PM -0500, Peter Bergner wrote:
> On 3/4/22 8:14 PM, Peter Bergner wrote:
> > On 3/4/22 11:33 AM, Peter Bergner wrote:
> >>> Ok pushed to trunk. I haven't determined yet whether we need this on GCC
> >>> 11 yet.
> >>> I'll check on that and report back. Thanks!
> >
Hi!
On Wed, Mar 16, 2022 at 12:20:18PM -0500, will schmidt wrote:
> For PR100693, we currently provide an addg6s builtin using unsigned
> int arguments, but we are missing an unsigned long long argument
> equivalent. This patch adds an overload to provide the long long
> version of the builtin.
>
On Wed, Mar 16, 2022 at 03:06:42PM -0500, will schmidt wrote:
> On Wed, 2022-03-16 at 13:12 -0500, Segher Boessenkool wrote:
> > (define_insn "addg6s"
> > [(set (match_operand:GPR 0 "register_operand" "=r")
> > (uns
> From: Piotr Kubaj
> Date: Sun, 20 Mar 2022 13:03:13 +0100
> Subject: [PATCH] fortran: on powerpc*-unknown-freebsd*, also use fpu-glibc
>
> It builds fine and correctly bulds packages on FreeBSD.
> It looks like "fpu-glibc" name is a bit misleading since it also works
> on FreeBSD.
>
> Signed-o
On Mon, Mar 21, 2022 at 02:14:08PM -0400, David Edelsohn wrote:
> On Mon, Mar 21, 2022 at 5:13 AM Jiufu Guo wrote:
> > There is a rare corner case: where __vector is followed only with ";"
> > and near the end of the file.
> This is okay. Maybe a tweak to the comment, see below.
This whole funct
Hi!
On Tue, Mar 22, 2022 at 01:50:39PM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> > On Mon, Mar 21, 2022 at 02:14:08PM -0400, David Edelsohn wrote:
> >> On Mon, Mar 21, 2022 at 5:13 AM Jiufu Guo wrote:
> >> > There is a rare corner case: where
On Tue, Mar 22, 2022 at 01:50:09PM +0100, Martin Liška wrote:
> Pushed as obvious.
> - warning (0, "passing argument %d of %qE discards const qualifier
> "
> - "from pointer target type", n + 1, fndecl);
> + warning (0, "passing argument %d of %qE discards % "
>
On Tue, Mar 22, 2022 at 01:39:12PM +0100, Martin Liška wrote:
> Pushed to master as obvious.
An obvious what? It is not an improvement, just a change.
> - error ("unknown vectorization library ABI type (%qs) for "
> + error ("unknown vectorization library ABI type %qs for "
>
On Wed, Mar 23, 2022 at 11:31:12AM +0100, Martin Liska wrote:
> --- a/gcc/config/rs6000/rs6000.cc
> +++ b/gcc/config/rs6000/rs6000.cc
> @@ -4345,8 +4345,8 @@ rs6000_option_override_internal (bool global_init_p)
> rs6000_veclib_handler = rs6000_builtin_vectorized_libmass;
> else
>
On Fri, Mar 25, 2022 at 02:51:38PM -0500, Peter Bergner wrote:
> This patch updates the POWER testsuite test cases using -mcpu= and -mtune=
> to use the preferred -mdejagnu-cpu= and -mdejagnu-tune= options. This also
> obviates the need for the dg-skip-if directive, since the user cannot
> overrid
On Fri, Mar 25, 2022 at 06:15:56PM -0500, Peter Bergner wrote:
> On 3/25/22 4:08 PM, Segher Boessenkool wrote:
> > On Fri, Mar 25, 2022 at 02:51:38PM -0500, Peter Bergner wrote:
> > It seems likely many of these tests should move to g++.target/powerpc .
>
> Probably, that can
Hi!
On Thu, Mar 24, 2022 at 10:00:43AM +0800, Kewen.Lin wrote:
> Commit r12-7687 exposed one miss optimization chance in function
> rs6000_maybe_emit_maxc_minc, for now it only considers comparison
> codes GE/GT/LE/LT, but it can support more variants with codes
> UNLT/UNLE/UNGT/UNGE by reversing
On Mon, Mar 28, 2022 at 12:26:02PM -0400, Michael Meissner wrote:
> However on power9 and power10 it generates:
>
> ;; vec_splats (vec_extract (src, 0))
> mfvsld 3,34
> mtvsrdd 34,9,9
>
> ;; vec_splats (vec_extract (src, 1))
> mfvsrd 9,34
> mtvsrdd 34,9,9
>
>
Hi!
On Mon, Mar 28, 2022 at 12:27:05PM -0400, Michael Meissner wrote:
> In looking at PR target/99293, I noticed that the code in the insn
> vsx_splat__reg used "vecmove" as the "type" insn attribute when the
> "mtvsrdd" is generated. It should use "mfvsr". I also added a "p9v" isa
> attribute f
Hi!
On Mon, Mar 28, 2022 at 12:28:04PM -0400, Michael Meissner wrote:
> In looking at PR target/99293, I noticed that the insn "type" attribute is
> incorrect for the vsx_extract_ insns. In particular:
>
> 1)Simple vector register move should be vecmove (alternative 1);
> 2)
On Mon, Mar 28, 2022 at 06:30:41PM -0400, Michael Meissner wrote:
> On Mon, Mar 28, 2022 at 12:14:09PM -0500, Segher Boessenkool wrote:
> > On Mon, Mar 28, 2022 at 12:26:02PM -0400, Michael Meissner wrote:
> > > However on power9 and power10 it generates:
> > >
> &g
On Mon, Mar 28, 2022 at 12:28:55PM -0400, Michael Meissner wrote:
> In looking at PR target/99293, I noticed that the vsx_extract_
> pattern for V2DImode and V2DFmode only allowed traditional floating point
> registers, and it did not allow Altivec registers. The original code was
> written a few
Hi!
On Tue, Feb 22, 2022 at 07:56:40PM -0600, Paul A. Clarke wrote:
> On Tue, Feb 22, 2022 at 06:41:45PM -0600, Segher Boessenkool wrote:
> > That said...
> >
> > > -/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
> > > -/* { dg-skip-if &quo
Hi!
On Mon, Feb 21, 2022 at 03:17:47PM -0600, Paul A. Clarke wrote:
> gcc/testsuite
> * g++.dg/debug/dwarf2/const2.C: Move to g++.target/powerpc.
> * g++.dg/other/darwin-minversion-1.C: Likewise.
> * g++.dg/eh/ppc64-sighandle-cr.C: Likewise.
This one uses
// { dg-do run { target
401 - 500 of 6130 matches
Mail list logo
