Hi!
On Fri, Sep 25, 2020 at 09:07:46AM -0500, Paul A. Clarke wrote:
> On Thu, Sep 24, 2020 at 06:22:10PM -0500, Segher Boessenkool wrote:
> > > + result [(__N & 0b)] = __D;
> >
> > Hrm, GCC supports binary constants like this since 2007, so okay. But I
> &g
On Fri, Sep 25, 2020 at 10:41:05AM -0500, will schmidt wrote:
> On Thu, 2020-09-24 at 19:40 -0500, Segher Boessenkool wrote:
> > > +++ b/gcc/testsuite/gcc.target/powerpc/vsx-load-element-extend-
> > > char.c
> > > @@ -0,0 +1,168 @@
> > > +/*
> > > +
], temp));
> > +DONE;
> > + }
> > + [(set_attr "type" "exts")])
>
> Don't need "type" attr on define_expand since the type will come from the 2
> individual insns emitted.
Yeah good point, those attrs do not even do anything on the expand as
far as I can see (do *any* attrs, even?)
Segher
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.
, which will make your patch much easier
to read. It looks like it will be fine, thanks :-)
Segher
st_int 0)))]
Why? This diverges the "dot" version from the non-dot for no reason.
(We can do 32-bit rotates on 64-bit implementations just fine, and even
the record ("dot") form works just fine; except for the setting of
"smaller than" in CR0. And we can fix that even (by not using 0,31 but
a wrapping mask, say, 1,0), but more readable generated code was more
important so far.)
I don't see a patch with splitters only? Huh. Did you attach the same
patch twice?
Since this won't be handled before combine (or what do I miss?), it is
fine to do splitters only (splitters for combine). But the other
approach is fine as well.
Thanks,
Segher
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 abou
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
& OPTION_MASK_PCREL) == 0))) \
> + SET_CMODEL (CMODEL_SMALL); \
Please write this in a more readable way? With some "else" statements,
perhaps.
It is also fine to SET_CMODEL twice if that makes for simpler code.
The rest looks fine, fwiw.
Segher
S: Support __PCREL__ code.
The patch does look fine. Okay for trunk (and backports if those are
wanted; discuss with Bill I guess). Thanks!
(But please explain the purpose of this, in the commit message if that
makes sense.)
Segher
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
>
;
>
> Ready for master?
This is okay for trunk, thanks! (It is trivial and obvious as well, so
please just commit things like this without prior approval.)
Segher
> * config/rs6000/rs6000-call.c: Include value-range.h.
> * config/rs6000/rs6000.c: Likewise.
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
can address them just as efficiently outside
> the TOC.
>
> * config/rs6000/rs6000.c (rs6000_linux64_override_options):
> Formatting. Correct setting of TARGET_NO_FP_IN_TOC and
> TARGET_NO_SUM_IN_TOC.
Okay for trunk. Thanks!
Segher
dress): Properly
> sign extend high part of address constant.
I would just say "use gen_int_mode" ;-) But this is fine, sure.
Segher
me to time, but that isn't unique to Power ;-)
There isn't a rule that we can just revert any patches that break
bootstrap on primary targets (and I am not suggesting there should be),
so breakage now and then is unavoidable. Maybe some CI thing can help
make stage 1 a less bumpy road.
Segher
> fine to do splitters only (splitters for combine). But the other
> > approach is fine as well.
>
> Patch #2 uses define_and_split like the x86 back-end; moreover, we already
> have define_and_split for the dot variants so maybe it's the best way to go?
Please just use define_split, or just define_insn. define_split if you
want this to be split during combine (how could that work here though?),
or define_insn if you think other passes can generate this as well.
define_insn_and_split is *both*, and that isn't useful here.
Do you see dot patterns for this used ever, btw?
Segher
u can do \M or even just a space instead of that
last \s, but this works fine.)
The rs6000 parts are fine (with the message improved perhaps). Thanks!
The rest looks fine to me as well, fwiw.
Segher
not all ways are supported by all compilers!
(Including older versions of the same compilers.)
- /* C89 namespace violation! */ \
- builtin_define ("CPU_FAMILY=PPC"); \
+ builtin_define ("CPU_FAMILY=PPC"); \
You removed the comment, but it is rather important still? Of course
the "C89" part of it is dated, but it is true for all newer language
standards just the same.
Cheers,
Segher
200
>
> Track access ranges in ipa-modref
>
> caused
[ ... ]
This isn't a patch. Wrong mailing list?
Segher
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
& 0x1e00) != fe)
FAIL;
and then see if more than one bit is set:
if (fe & (fe - 1))
FAIL;
but also disallow zero:
if (!fe)
FAIL;
Or, you can just put the bit number in the switch cases for the four
bits. There are only four, after all.
Thanks,
Segher
int4.
Yeah, utf8 c2 a0, aka u+00a0. Replacing that with an actual space is of
course okay (and trivial and obvious). Thanks!
(Bonus points if you do all of doc/*.texi :-) )
Segher
2): Rename
> to BU_P10_POWERPC64_MISC_2.
> (CFUGED,CNTLZDM,CNTTZDM,PDEPD,PEXTD): Call renamed macro.
(space after comma?)
Segher
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 *
this. But thanks for trying! :-)
(Don't let me dicsourage you btw, most is pretty straightforward).
> * config/rs6000/rs6000.h (TARGET_CTZ): Replace with
> TARGET_MODULO.
Changelogs are indented with tabs, and this fits on one line.
So, please make TARGET_P7 and such, and OPTION_MASKs for those in
rs6000-cpus.def?
Segher
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.
ywhere. "fmin" and
"fmax" seem to be good names :-)
Segher
mantics,
we can generate code for that with -ffast-math as well, since the
code generated is optimal in either case; it's just the *generic*
optimisations that fall behind.
Segher
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
is no need for altivec_ok in any case, the -mcpu=
guarantees it is satisfied.
> +/* It's to verify no ICE here. */
"This used to ICE."?
Please commit this now, looks good. Thanks!
Segher
Verify there is no ICE on 32 bit environment. */
/* This used to ICE with the SYSV ABI (PR96072). */
Please use -O2 if that works here.
Okay for trunk. Thank you!
Segher
s_arch_ tests if the compiler is asked to generate
code for (which is reflected in the _ARCH_* preprocessor symbols,
hence the name).
Okay for trunk with the correct check_effective_target_* . Thanks!
Segher
target-specific (since we are the only
one implementing it), so :-) I know it is borderline.
Segher
er.
> -The maximum value of @var{N} and @var{M} is 65535.
> +The maximum value of @var{N} and @var{M} is 65535. On PowerPC with the
> +ELFv2 ABI, for one function with dual entry points, the supported values
> +for @var{M} are 0, 2, 6 and 14.
"for a function"
Okay for trunk with those trivial chnges. Thanks!
Segher
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 should ensure that option powerpc64 is
> >> independent of -m
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
error, but a warning, and then we force
> 64b on (taking
> the user’s intention to be specified by the explicit ‘-m64’).
And that is wrong. Any silent overriding of what the user says is bad.
Not overriding it (and then later ICEing) is bad as well, so it should
be an error here. And in generic code anyway.
Segher
introducing more special cases like this.
> +#ifdef OS_MISSING_POWERPC64
> + else if (OS_MISSING_POWERPC64)
> + /* It's unexpected to have OPTION_MASK_POWERPC64 on for OSes which
> +miss powerpc64 support, so disable it. */
> + rs6000_isa_flags &= ~OPTION_MASK_POWERPC64;
> +#endif
All silent stuff is always bad.
If things are done well, we will end up with *less* code than what we
had before, not more!
Segher
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
in the past. Compare to -maltivec, which often is used with -mcpu=750
and stuff like that.
We want to have less like this (much less), to reduce exponential
special cases and exponential testing requirements to something
manageable, but we also want to not break the world :-)
Segher
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
pc*-*-freebsd*, but leave the others alone (and update this as needed
> later)?
Ah. This error should be generated by generic rs6000 code, not
separately by separate targets. Dunno if you want to fold that into the
current patch series.
Segher
ult_print_patchable_function_entry_1 (file, patch_area_size, record_p,
> - flags);
> + default_print_patchable_function_entry (file, patch_area_size, record_p);
> }
Please don't define TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY at all,
instead, and remove this whole function?
The rs6000 changes are okay like that, thanks!
Segher
ind this documented anywhere. If this is not true, this part of the
patch is incorrect.
Segher
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
" }, \
>{"tune_64", "%{" OPT_ARCH64 ":%{!mtune=*:%{!mcpu=*:-mtune=%(VALUE)}}}" }, \
So this patch will make a difference to people who use --with-abi= for
one of the ABI variant things.
But it does not seem correct. -mabi=optionA should not override the
-mabi=optionB set in --with-abi=, where A and B are independent, nor
should it override the base ABI.
Please open a PR for the problem you want to solve here, so we do not
lose track of it?
Thanks,
Segher
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
al { scan-assembler-times {\maddg6s\M} 4 } } */
> +/* { dg-final { scan-assembler-not"bl __builtin" } } */
Some ABIs will use tailcalls here. You can prevent that in the
testcase (add an asm(""); before the return statement), or you can
scan for something less specific than the exact "bl"?
> +unsigned long long test4_ull (unsigned long long *a, unsigned long long *b)
> +{
> + return __builtin_addg6s(*a, *b);
> +}
This does not work with -m32, no?
Segher
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
for memory at least!)
> +/* { dg-final { scan-assembler-not {\mmfvsrd\M} } } */
> +/* { dg-final { scan-assembler-not {\mmfvsrld\M}} } */
> +/* { dg-final { scan-assembler-not {\mmtvsrdd\M}} } */
You could just do
> +/* { dg-final { scan-assembler-not {\mm[ft]vsr}} } */
and even all future variants would be handled :-)
Looks good, just those last details :-)
Segher
etween the two then. Copied code easily turns into a maintenance
nightmare, after all.
And then I just forgot, it fell off my to-do lists, sorry.
The patch is okay for trunk, with a suitable changelog. Thanks! Do you
want backports for this as well?
Segher
}. 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
easily added back,
>but wasting GTY just in case...
> 5) actually syncs __SIZEOF_FLOAT128__ with the __float128 macro being
>defined in addition to __ieee128 being usable
>
> Now, in the PR Segher said he doesn't like 5), but I think it is better
> to match the r
ermail/libc-testresults/2022q1/009421.html
Thanks for the report! This is now PR104829.
Segher
#x27; is an optional vector: if a closeparen follows,
just store NULL for this element. */
(optional vectors are at the end of an RTX), and if you write [] you
will hit
fatal_with_file_and_line ("vector must have at least one element");
Segher
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
t disable any effect from this flag, instead? It should just
be implied by -mcpu=power8, and be impossible to be enabled otherwise
(or disabled!)
Segher
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
at implements Book III-E of ISA 2.07
(nothing in GCC, but no actual CPU either). Or Category: Embedded even
maybe :-)
It could be clearer perhaps, or just be removed completely; it might
have been useful historically, but it isn't anymore really.
Segher
return 2;
> + else if (GET_CODE(XEXP(src, 1)) == CONST_INT &&
> CMPRESD_OPERAND(INTVAL(XEXP(src, 1
> + return 2;
REG_P, CONST_INT_P
> +#define CMPRESD_OPERAND(VALUE) \
> + (VALUE < 32 && VALUE >= -32)
IN_RANGE ((VALUE), -32, 31)
Using a predicate might be better? Note you need parens around macro
params, btw.
> +/* True if VALUE is an unsigned 5-bit number. */
> +#define UNSIGNED_CMPRESD_OPERAND(VALUE) \
> + (VALUE < 64 && VALUE >= 0)
IN_RANGE ((VALUE), 0, 63)
Segher
? If not, this is okay for trunk. Thanks!
Segher
branch is broken)
Mike, please revert it then?
Segher
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
essions.
> > Ok for the GCC 11 and GCC 10 release branches after a day or two of baking
> > on
> > trunk?
>
> Ping.
>
> The trunk patch has been confirmed to fix the glibc build errors and no issues
> with the patch has surfaced, so ok for the GCC11 and GCC10 release branches?
If you can confirm it fixes the glibc build error on 11 and 10 as well,
then yes please. Thanks!
Segher
;register_operand" "r")]
UNSPEC_ADDG6S))]
"TARGET_POPCNTD"
"addg6s %0,%1,%2"
[(set_attr "type" "integer")])
We do not want DI (here, and in most places) for -m32!
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr100693.c
> @@ -0,0 +1,68 @@
> +/* { dg-do compile { target { powerpc*-*-linux* } } } */
Why only on Linux?
> +/* { dg-skip-if "" { powerpc*-*-darwin* } } */
Why not on Darwin? And why skip it anyway, given the previous line :-)
> +/* { dg-require-effective-target powerpc_vsx_ok } */
That is the wrong requirement. You want to test for Power7, not for
VSX. I realise you probably copied this from elsewhere :-( (If from
another addg6s testcase, just keep it).
Segher
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
ks
> on FreeBSD.
>
> Signed-off-by: Piotr Kubaj
Okay for trunk. Thanks!
Segher
need to examine the 'tok' parameter. */
... followed by 17 uses of "tok". Yes, some of those overwrite the
function argument, but that doesn't make it any better! :-P
Some factoring would help, too, perhaps.
Segher
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
quot;passing argument %d of %qE discards % "
> + "qualifier from pointer target type", n + 1, fndecl);
Please use %qs instead?
Segher
library ABI type %qs for "
>"%qs switch", rs6000_veclibabi_name, "-mveclibabi=");
Can you make it print -mveclibabi=something instead? With some
wordsmithing of course... "unknown vectorization library type in
-mveclibabi=blubber" or something?
Segher
"%<-mveclibabi=%s%>", rs6000_veclibabi_name);
"ABI type".
Okay for trunk with that restored. Thanks!
Segher
those tests should use has_arch_pwrN).
> +++ b/gcc/testsuite/gcc.target/powerpc/int_128bit-runnable.c
> +++ b/gcc/testsuite/gcc.target/powerpc/test_mffsl.c
I missed these two in reviewing when the -mcpu= was introduced, oops.
Okay for trunk. Also okay for backports if you want / if you think it
useful. Thanks!
Segher
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
; btw, LT is by no means more
standard than UNGE is. You can say you are folding things so you later
have to support fewer cases, or similar?
Thanks,
Segher
3] = GEN_INT (which_word ? 3 : 0);
> + return "xxpermdi %x0,%x1,%x1,%3";
Please use gen_vsx_xxspltd_v2di, instead. Which itself should not use
an unspec of course, but that is another patch.
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr99293.c
> @@ -0,0 +1,36 @@
> +/* { dg-do compile { target powerpc*-*-* } } */
Don't. This is gcc.target/powerpc/ already.
> +/* { dg-final { scan-assembler-times "xxpermdi" 4 } } */
\m \M
Thanks,
Segher
"*,p9v")])
"we" requires "p9v". Please do a full conversion when getting rid of
this? That includes requiring TARGET_POWERPC64 for it (not -m64 as its
documentation says; the existing implementation of "we" is correct).
Segher
"veclogical,mfvsr,mfvsr,vecperm")
> + [(set_attr "type" "vecmove,vecperm,mfvsr,mfvsr")
> (set_attr "isa" "*,*,p8v,p9v")])
The generated code is one of
no-op
mfvsrd
fmr
xxlor
mfvsrld
xxpermdi
Which of the 4 alts are meant to correspond to which of those six
possible generated pieces of code?
Segher
401 - 500 of 6091 matches
Mail list logo
