t; + rtx cr6 = gen_rtx_REG (CCmode, CR6_REGNO);
> + rtx condition_rtx = gen_rtx_ (SImode, cr6, const0_rtx);
> + rtx_code cond_code = GET_CODE (condition_rtx);
That GET_CODE always would return , fwiw.
You shouldn't need anything like this, bcdinvalid will work just fine if
written as bcdadd_ov (with vector of 0 as the second op)?
Segher
"* something" isn't a type. "something *" is.
Tested and committed.
Segher
2022-06-17 Segher Boessenkool
* config/rs6000/rs6000.cc (rs6000_invalid_conversion): Correct some
types.
---
gcc/config/rs6000/rs6000.cc | 8
1 file changed, 4 i
Hi!
On Fri, Jun 17, 2022 at 04:19:37PM +0800, HAO CHEN GUI wrote:
> On 16/6/2022 下午 7:24, Segher Boessenkool wrote:
> > You shouldn't need anything like this, bcdinvalid will work just fine if
> > written as bcdadd_ov (with vector of 0 as the second op)?
>
> The vector
>
> Peter
>
> gcc/
> PR c/106016
> * expr.cc (count_type_elements): Handle OPAQUE_TYPE.
>
> gcc/testsuite/
> PR c/106016
> * gcc.target/powerpc/pr106016.c: New test.
The testcase is fine everywhere. Thanks!
Segher
On Mon, Jun 20, 2022 at 09:48:34AM +0200, Sebastian Huber wrote:
> On 04/04/2022 11:31, Sebastian Huber wrote:
> >Hello Segher,
> >
> >On 15/03/2022 23:29, Segher Boessenkool wrote:
> >>On Tue, Mar 15, 2022 at 03:29:23PM +0100, Sebastian Huber wrote:
> >>
of
course, but it isn't invalid RTL.
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr105991.c
> @@ -0,0 +1,11 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +unsigned long long
> +foo (unsigned long long value)
> +{
> + value &= 0x;
> + value |= value << 32;
> + return value;
> +}
> +/* { dg-final { scan-assembler "rldimi" } } */
Write
/* { dg-final { scan-assembler {\mrldimi\M} } } */
please.
Okay for trunk with those changes. Thanks!
Segher
[(set_attr "type" "fp")]
> +)
Are things like
fmin(4.0, 2.0);
(still) optimised correctly?
> new file mode 100644
> index 000..e43ac40c2d1
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr103605.c
> +/* { dg-options "-O1 -mvsx" } */
Please use -O2 instead. That way, it will catch it if any of the
optimisations that are normally done (and not with just -O1) sabotage
us here.
Thanks,
Segher
that is not enough).
So let's just do lp64, at least for now :-)
Segher
Hi!
On Thu, Jun 16, 2022 at 03:47:49PM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> >> >> --- a/gcc/testsuite/gcc.target/powerpc/medium_offset.c
> >> >> +++ b/gcc/testsuite/gcc.target/powerpc/medium_offset.c
> >> >> @@ -1,7 +1,7 @
other contexts as well.
So this needs some bigger surgery.
Segher
bvious.
The combine pass still has explicit support for subregs of memory, and
the support for subregs is one of the more error-prone and non-obvious
parts of combine in the first place. Anything that makes things harder
here will not be approved.
Segher
Hi!
On Fri, Jun 24, 2022 at 09:03:59AM +0800, Kewen.Lin wrote:
> on 2022/6/24 03:06, Segher Boessenkool wrote:
> > On Wed, May 18, 2022 at 10:07:48PM +0800, Kewen.Lin wrote:
> >> As PR103353 shows, we may want to continue to expand a MMA built-in
> >> function like a
a nonzero_bits that is a subset of the one
combine saw, and thus, the insn no longer matches (as Ke Wen has
encountered. Often you do not see this in your testing, but almost
always someone will report an ICE within days!)
[Btw, you posted the patch as quoted-printable, which means other
people can not apply the patch.]
Segher
ons.
In the other direction, other passes can call split_insns as well, of
course. Nothing currently does, but that does not change much :-)
Segher
t; -return "rlwimi %0,%1,%h2,32-%h2,31";
> - else
> -return "rldimi %0,%1,%H2,64-%H2";
> -}
> + "INTVAL (operands[2]) + exact_log2 (-UINTVAL (operands[4])) == 32"
> + "rlwimi %0,%1,32-%h2,%h2,31"
>[(set_attr "type" "insert")])
I was going to say this is not an improvement at all, because now you
need that big comment. There are many tricky details here, more
important ones than the comment talks about. It is better to show such
things in the code instead.
But it already does show that :-) The patch is okay with that four-line
comment deleted (and the indentation fixed). Thanks!
Segher
It is easier to understand that way.
With or without that, okay for trunk. Thanks!
Segher
The previous version returned true for all PowerPC. This is incorrect.
We only support floating point square root instructions if a) we support
floating point instructions at all, and b) we have _ARCH_PPCSQ defined.
2020-03-09 Segher Boessenkool
* testsuite/lib/target-supports.exp
Hi!
On Wed, Mar 03, 2021 at 06:07:29PM -0300, Alexandre Oliva wrote:
> On Mar 3, 2021, Segher Boessenkool wrote:
> It's skipping the test, as the change you propose, that reduces testing
> surface, when testing only a configuration that ends up skipping it.
Not at all. There
Hi!
On Wed, Mar 03, 2021 at 02:12:56PM -0500, Michael Meissner wrote:
> On Tue, Mar 02, 2021 at 03:53:06PM -0600, Segher Boessenkool wrote:
> > If you want to make decimal and/or QP float work only on 64-bit LE Linux
> > you should say so. And in that case, that is certainly
It needs the int128 selector because it uses __int128, and the lp64
selector is the best we can do for -mcmodel=.
2021-03-10 Segher Boessenkool
gcc/testsuite/
* gcc.target/powerpc/pr98959.c: Add int128 and lp64 selectors.
---
gcc/testsuite/gcc.target/powerpc/pr98959.c | 2 ++
1 file
> If it wasn't associated with the type,
It isn't. It is a function attribute.
> > but it does look better than just a global flag.
The flag is just for setting a default, which often is handy (esp. for
code that is too humonguous to compile without it: it is a simple flag
to add, and your program was probably slow to begin with, being huge and
all).
Segher
ee the first entry on
https://gcc.gnu.org/onlinedocs/gcc/PowerPC-Function-Attributes.html
Given Martin's and Richard's replies, I think we should not take this
patch. Sorry.
Segher
On Wed, Mar 10, 2021 at 02:06:24AM -0300, Alexandre Oliva wrote:
> On Mar 9, 2021, Segher Boessenkool wrote:
>
> > +return [check_no_compiler_messages powerpc_sqrt object {
>
> I don't think you really need to assemble this. s/object/assembly/
> would do. Even
t used in
all configurations (like, powerpc64-darwin*, and the AIX configs). So
no, sorry; you'll need more work here.
Btw, aarch64 has this same option.
Segher
targetm.max_anchor_offset = 32767;
> + targetm.const_anchor = 0x8000;
> +}
Why only on 64 bit? Why these choices?
Segher
tch does a simple workaround.
2021-03-16 Segher Boessenkool
PR target/98092
* config/rs6000/predicates.md (branch_comparison_operator): Allow
ordered and unordered for CCFPmode, if flag_finite_math_only.
gcc/testsuite/
PR target/98092
* gcc.target/power
(tmp, tmp, GEN_INT (8)));
> > + emit_insn (gen_adddi3 (tmp, tmp, GEN_INT (8)));
> > }
> >else
> > {
> > - emit_insn (gen_mulsi3 (tmp, idx, GEN_INT (width)));
> > - emit_insn (gen_subsi3 (tmp, GEN_INT (24 - width), tmp));
> > + emit_insn (gen_muldi3 (tmp, idx, GEN_INT (width)));
> > + emit_insn (gen_subdi3 (tmp, GEN_INT (24 - width), tmp));
>
> Ditto. But the above was even inconsistent, sometimes it
> used tmp (for LE) and otherwise idx in whatever mode it has.
Thanks for the review Jakub, I kinda dropped this :-(
Segher
this bug, as the use of opaque modes for the MMA types
> "fixed" this issue there.
>
> This passed bootstrap and regtesting on powerpc64le-linux with no regressions.
> Ok for the GCC 10 release branch?
Yes, this is okay. Thanks!
Segher
> 2021-03-16 Peter Bergn
;d like to know what it is trying to achieve, what it is trying to
improve!
Segher
Hi!
On Fri, Mar 19, 2021 at 10:46:54AM +0800, Kewen.Lin wrote:
> As Segher and Mike pointed out, the define_insn_and_split should avoid
> to use empty split condition if the condition for define_insn isn't empty,
> otherwise it can sometimes leads to unexpected consequence.
>
&
Tested on powerpc64-linux {-m32,-m64}. No regressions. Is this okay
for trunk?
Segher
2021-03-19 Segher Boessenkool
PR target/97926
* ubsan.c (ubsan_instrument_float_cast): Don't test for unordered if
there are no NaNs.
---
gcc/ubsan.c | 12 ++--
1
s, because that might well break things for some targets, or
change behaviour at least, it is a GCC 12 thing. It will be a nice
cleanup though :-)
Segher
Hi!
On Sat, Mar 20, 2021 at 10:53:32AM -0400, Vladimir Makarov via Gcc-patches
wrote:
> It seems CONSTRAINT_LEN treats constraint '\0' as one having length 1.
Maybe we should fix that? See attached patch.
Segher
diff --git a/gcc/genpreds.c b/gcc/genpreds.c
index 8499a2a2383b.
On Mon, Mar 22, 2021 at 10:22:55AM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Sat, Mar 20, 2021 at 10:53:32AM -0400, Vladimir Makarov via Gcc-patches
> > wrote:
> >> It seems CONSTRAINT_LEN treats constraint '\0' as one having length 1
ad.c:
>
> switch ((c = *p, len = CONSTRAINT_LEN (c, p)), c)
> {
> case '\0':
> len = 0;
> break;
>
> ...
>
> I think we could wait stage 1 to do this.
Yes. And such gcc_unreachable should be in as high-level code as
possible, not deep in some macro.
Segher
tring "yes")
> - (const_string "no")))])
> + (set (attr "prepend_prefixed_insn")
> + (if_then_else (match_test "TARGET_PREFIXED")
> + (const_string "yes")
> + (const_string "no")))])
(bad whitespace)
I don't think this is correct. We need to force the use of "plq" here
(for LE only actually, that should be fixed some day). Maybe we should
have a separate instruction pattern for it, even, since its semantics
differ very significantly :-)
Segher
6000.c (rs6000_expand_vector_set_var_p9):
> > Convert idx to DImode.
> > (rs6000_expand_vector_set_var_p8): Likewise.
> >
> > gcc/testsuite/ChangeLog:
> >
> > 2021-03-18 Xionghu Luo
> >
> > PR target/98914
> > * gcc.target/powerpc/
he new libc (but usually not). This is normal.
Segher
sprintfieee128;
(well, an alias). But you cannot, because of the dependency inversion
you have. But independent declarations like this are the source of many
bugs :-(
Hrm. This patch won't make things worse than they are, so, okay for
trunk. Thanks!
Segher
we should not build the
> > conversions. And we want to eliminate the stdio.h dependency. I will look
> > at
> > it unless somebody has already fixed it.
>
> This issue is still present.
>
> What about the patch below?
>
> Thanks,
> Florian
>
> rs600
pot, not at the end of file.
You'll get fewer patch conflicts, as happy by-effect.
> + rtx (*gen_ashl)(rtx, rtx, rtx);
> + rtx (*gen_lvsl)(rtx, rtx);
> + rtx (*gen_lvsr)(rtx, rtx);
All this stuff will be unneeded with parameterised names :-)
I'll fix up the nits and commit it for you, as we discussed. Thank you!
Segher
_test "!TARGET_PREFIXED")
> - (match_test "!NONJUMP_INSN_P (insn)"))
> + (match_test "!NONJUMP_INSN_P (insn)")
> + (eq_attr "maybe_prefixed" "no"))
>(const_string "no")
It's a cond, so you can have separate cases instead of ior, if that
reads better (the generated compiler code will be equivalent). It can
help if you want to place some comments, for example ;-)
Okay for trunk. Thank you!
Segher
werpc/pr99842.C
> @@ -0,0 +1,188 @@
> +/* PR target/99842 */
> +/* { dg-require-effective-target power10_ok } */
> +/* { dg-options "-O3 -mdejagnu-cpu=power10 -w" } */
(Please document what warning you want to shut up. Just a few words is
plenty.)
That testcase will likely not show the error anymore just a year or so
from now, but it is good to have more complex testcases anyhow.
Segher
mp; lp64 } } */
> // { dg-require-effective-target o_flag_in_section }
> /* { dg-options "-O0 -fpatchable-function-entry=1" } */
> /* { dg-additional-options "-fno-pie" { target sparc*-*-* } } */
"not supported", instead.
Okay for trunk. Thank you!
(Sorry this took so long, has to do a lot of archaeology and research,
pretty much nothing here is documented :-/ )
Segher
instead of
> _floatunsditf. Add tf <-> ti conversion objects.
> (IBM128_SHARED_OBJS): Use proper substitution reference syntax.
Okay for trunk. Thank you!
Segher
Wpsabi warns about such uses.
>
> powerpc-ibm-aix* already silences these warnings with -Wno-psabi;
> this patch extends that to powerpc-wrs-vxworks* too.
Okay for trunk. Thanks!
Segher
> * gcc.dg/ipa/ipa-sra-19.c: Extend -Wno-psabi to ppc-vx7r2.
But they do make sure it is defined, they use -mcpu=power9 (etc.). What
is different in your setup that that does not work?
Segher
on x86_64-linux and i686-linux, ok for trunk?
Okay for trunk. Thank you!
Segher
> 2021-04-08 Jakub Jelinek
>
> PR rtl-optimization/99905
> * combine.c (expand_compound_operation): If pos + len > modewidth,
> perform the right shift by pos in in
s embedded in it, it will happily propagate it
> into DEBUG_INSNs and cause problems later (in this case ICEs during LRA).
It should never get that far.
(We talked about this; just adding it here to archive it for posterity.)
Segher
x86_64-linux and i686-linux, ok for trunk?
Okay for trunk. Thank you!
We'll need to audit all other code doing similar things as well, or add
some assert at some strategic spot. Something for GCC 12 :-)
Segher
; or "New instructions." or
similar. The changelog says *what*, not *why*. And it is important
that you can find stuff in it using grep or similar.
Here it should say "s3 for IEEE128". We actually have
some patterns that just say "3", not too useful in a
changelog if you do not say what code and mode are! (In this case, it
does not help to say what "minmax" is from, it stand for just "min" and
"max" after all :-) )
Segher
ctions.
And rephrase this, just "New" something.
So please resend, taking into account all comments.
Segher
; I'm not sure about this one though. The REGNO checks mean that this is
> effectively for hard registers only. I thought one of the reasons for
> make_more_copies was to avoid combining hard registers like this, so I'm
> not sure we should have a pattern that specifically ta
On Wed, Apr 14, 2021 at 06:42:33PM +0100, Richard Sandiford wrote:
> Otherwise this looks good apart from the open question about whether
> we should be doing complex combinations involving hard regs. Let's see
> what Segher says about that side.
It works find with pseudos as well
On Wed, Apr 14, 2021 at 06:55:56PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > The REGNO checks work fine for pseudos as well. But, why does it do
> > this at all, instead of using match_dup? That should be clearer.
>
> The register is appearing in two
On Wed, Apr 14, 2021 at 08:01:11PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 14, 2021 at 12:46:43PM -0500, Segher Boessenkool wrote:
> > The REGNO checks work fine for pseudos as well. But, why does it do
> > this at all, instead of using match_dup? That should be clearer.
>
28 a, __float128 b, double x, double y)
> > > +{
> > > + return (x != y) ? a : b;
> > > +}
>
> I would think the above should be == since it's named eq_ and
> the body would be redundant to ne_f128_d below as is.
Good spot :-)
Segher
On Wed, Apr 14, 2021 at 03:09:13PM -0400, Michael Meissner wrote:
> On Tue, Apr 13, 2021 at 05:19:12PM -0500, Segher Boessenkool wrote:
> > > * config/rs6000/rs6.h (FLOAT128_MIN_MAX_FPMASK_P): New macro.
> >
> > As said in the other mail, don't do the macro; ju
wa")
> + (match_operand:FPMASK 4 "vsx_register_operand" "wa")))]
>"TARGET_P9_MINMAX"
> "xxsel %x0,%x4,%x3,%x1"
>[(set_attr "type" "vecmove")])
Please keep that a "*"; it should be generated via "movcc".
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/float128-cmove.c
> @@ -0,0 +1,93 @@
> +/* { dg-final { scan-assembler {\mxxsel\M}} } */
> +/* { dg-final { scan-assembler-not {\mfsel\M} } } */
It is somewhat problematic to require xxsel and disallow fsel (for one
thing, the compiler could always generated xxsel instead of any fsel).
But it will probably keep working fine, the routines here are very
short.
> +__float128
> +eq_f128_d (__float128 a, __float128 b, double x, double y)
> +{
> + return (x != y) ? a : b;
> +}
So "==" here.
Segher
On Wed, Apr 14, 2021 at 09:20:33PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 14, 2021 at 01:47:04PM -0500, Segher Boessenkool wrote:
> > A subreg:QI of the match_dup should match fine. You can use a subreg
> > wherever GCC tries to match a reg.
> >
> > > matc
On Wed, Apr 14, 2021 at 09:25:46PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 14, 2021 at 01:47:04PM -0500, Segher Boessenkool wrote:
> > > and I must say I don't know if make_more_copies was meant to
> > > split insn 2 into (set (reg:QI pseudo) (reg:QI 0 x0)) a
On Wed, Apr 14, 2021 at 09:45:35PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 14, 2021 at 02:42:54PM -0500, Segher Boessenkool wrote:
> > > provably doesn't (that is from the splitter I wrote for the non-hard
> > > regs),
> > > nor
> > >
If the register named in an existing REG_UNUSED note dies somewhere
between where the note used to be and I3, we should just drop it.
2021-04-21 Segher Boessenkool
PR rtl-optimization/99927
* combine.c (distribute_notes) [REG_UNUSED]: If the register already
is dead
Hi!
On Sun, Apr 18, 2021 at 05:24:50PM +0200, Jakub Jelinek wrote:
> On Sun, Apr 18, 2021 at 03:03:07PM +0000, Segher Boessenkool wrote:
> > If the register named in an existing REG_UNUSED note dies somewhere
> > between where the note used to be and I3, we should just drop it.
&
On Sun, Apr 18, 2021 at 12:03:39PM -0500, Segher Boessenkool wrote:
> On Sun, Apr 18, 2021 at 05:24:50PM +0200, Jakub Jelinek wrote:
> > On Sun, Apr 18, 2021 at 03:03:07PM +0000, Segher Boessenkool wrote:
> > > If the register named in an existing REG_UNUSED note dies somewhere
&
There are various non-IBM CPUs with isel as well, so it is easiest if we
just don't consider that flag here (it is not needed).
2021-04-20 Segher Boessenkool
PR target/100108
* config/rs6000/rs6000.c (rs6000_machine_from_flags): Do not consider
OPTION_MASK
r4,r4,3 /* # doublewords to move */
> addir9,r3,-8/* adjust pointer for stdu */
> mtctr r4
> blt cr1,.Labort
Not sure... It should use cmpwi as well though, and then it is easier
to see.
Segher
trunk. Okay for backport to 11 when that branch opens again.
Does this need more backports? (Those should follow after 11 of
course).
Thanks,
Segher
On Fri, Apr 23, 2021 at 06:24:07PM -0400, Michael Meissner wrote:
> On Thu, Apr 22, 2021 at 05:56:32PM -0500, Segher Boessenkool wrote:
> > As Will says, it looks like the ELFv2 version has the same bug. Please
> > fix that the same way.
>
> Yes it has the same bug. However
t", CONST, altivec_eqv1ti)
Could / should this use vector_eqv1ti instead?
Do you perhaps have a testcase for the eq/eqv mixup thing? Don't spend
too much time on it, but maybe you have something.
Okay for trunk with that vector_eqv1ti change if that works (and is a
good idea etc.), and without it otherwise. Thanks!
Segher
e recommended, and
don't pretend these are "rules" at all. They are not. The important
thing is to make it easy for *others* to work with your patches. Adding
frivolities does not help; concise, well-phrased, terse *does* help.
Segher
-line subjects.
Ah, anmd don't send patches as replies, certainly not without changing
the email subject! I did not notice there was an updated patch
downthread when I sent my reply.
Segher
ot. We need guidelines that encourage people to write good subjects
with that single goal in mind, and all other guidelines (or "rules") are
counterproductive.
Segher
in (without blowing the 50 char limit)
then sure; and as I said before, well-chosen headings can be shorter
than free-form text expressing the same.
Segher
On Tue, Jun 15, 2021 at 02:12:31PM +0100, Jonathan Wakely wrote:
> On Tue, 15 Jun 2021 at 14:03, Segher Boessenkool wrote:
> >
> > On Mon, Jun 14, 2021 at 05:25:56PM +0100, Jonathan Wakely via Gcc-patches
> > wrote:
> > > We don't currently say document a
On Tue, Jun 15, 2021 at 05:04:51PM +0200, Jakub Jelinek wrote:
> On Tue, Jun 15, 2021 at 09:24:44AM -0500, Segher Boessenkool wrote:
> > IMNSHO this all should emphasise *why* these things are recommended, and
> > don't pretend these are "rules" at all. They are no
for 3 is earlyclobber, hence can't be the same as
> input 2.
> * config/rs6000/genfusion.pl (gen_logical_addsubf): Add
> earlyclobber to alts 0/1.
You can break that line later, after "to" even. Just FYI :-)
This is okay for trunk and backport to 10. Thanks!
Segher
rately from all other float.
We will still need to test if float is enabled at all so it won't help
all that much immediately, alas.
With that TARGET_POWER10 condition fixed: okay for trunk, and for 11
once it is tested for trunk on all systems. Thanks!
Segher
dg-final { scan-assembler {\mxsmincqp\M} { target {
> has_arch_pwr10 } } } } */
> +/* { dg-final { scan-assembler {\mxsmaxcqp\M} { target {
> has_arch_pwr10 } } } } */
You can write just { target has_arch_pwr10 } here, I think? Please do
so (if that works, I haven't actually tested it :-) )
Segher
uster using
> make -j 4.
I am building it on powerpc64-linux (-m32,-m64) and poweerpc64le-linux
currently. (All CentOS 7 fwiw).
It does not want to build gm2tools, haven't investigated that yet
either.
Will report results later. Thanks for your persistence!
Segher
hat and make yourself familiar with the repository and
> branch layout.
I've pushed a branch with the patches in the first post in this thread
to users/segher/heads/gm2 . Maybe it can help; I'll delete it to reduce
confusion when something more official shows up :-)
> I see there a
ou didn't have that problem when your REs
didn't end in text, of course. \m isn't so important here of course,
but it is easier to just add it than to reason about if you need it.
I take it you have checked that the new counts are correct and/or
expected.
This is okay for trunk, and for 11 too once it has shown reasonable
results for all configs these tests failed on before. Thanks!
Segher
Hi!
On Fri, Jun 18, 2021 at 10:00:40PM +0100, Gaius Mulley wrote:
> Segher Boessenkool writes:
> > On Thu, Jun 17, 2021 at 11:26:41PM +0100, Gaius Mulley via Gcc-patches
> > wrote:
> >> Debian Stretch using make -j 4, x86_64 GNU/Linux Debian Stretch built
> >>
On Sat, Jun 19, 2021 at 09:09:05AM -0500, Segher Boessenkool wrote:
> powerpc64-linux now is building, and is running the tetsuite. My
> powerpc64le-linux build used --enable-languages=all, but Ada fails to
> build, so I'll redo that without Ada.
For powerpc64
: Guarded
> with FLOAT128_HW_INSNS_ISA3_1.
"Guard", not "Guarded", all entries are written in the imperative, like,
"Do this" or "Guard that".
> +#ifdef FLOAT128_HW_INSNS_ISA3_1
> TFtype __floattikf (TItype_ppc)
>__attribute__ ((__ifunc__ ("__floattikf_resolve")));
I wonder if we now need TItype_ppc at all anymore, btw?
Okay for trunk with the changelog slightly massaged. Thanks!
Segher
say *why* it is disabled.
Okay for trunk like that. Also okay for 11 if it regstraps. Thanks!
Segher
tes.
Right, and I build and regcheck GCC with LANG=C (and no LC_*) so I
should never see anything translated at all, and nothing should generate
UTF-8 for me.
Segher
nymore, btw?
>
> Sorry that I don't quite follow this question.
I thought it may do the same as just TItype now, but the ifunc stuff
probably makes it different still :-)
Segher
> +f_ifunc (void)
> +{
> + __typeof (f) *res = x ? f_power9 : f_power8;
> + return res;
> +}
The testcase should say what it is testing for, it is not obvious?
Segher
Again, I put it in case somebody builds a BE power10 compiler.
This should still be fixed. And yes, people do test BE p10, of course.
And BE p10 *should* enable the QP float insns. Does it not currently?
Segher
On Thu, Jun 24, 2021 at 05:32:20PM +0800, Kewen.Lin wrote:
> on 2021/6/24 上午12:58, Segher Boessenkool wrote:
> > On Wed, Jun 23, 2021 at 12:17:07PM +0800, Kewen.Lin wrote:
> >>>> +#ifdef FLOAT128_HW_INSNS_ISA3_1
> >>>> TFtype __floattikf (TItype_p
On Thu, Jun 17, 2021 at 04:11:40PM -0400, Michael Meissner wrote:
> On Thu, Jun 17, 2021 at 01:11:58PM -0500, Segher Boessenkool wrote:
> > > --- a/gcc/testsuite/gcc.target/powerpc/float128-minmax.c
> > > +++ b/gcc/testsuite/gcc.target/powerpc/float128-minmax.c
> > >
On Mon, Jun 28, 2021 at 04:15:15PM +0800, Kewen.Lin wrote:
> on 2021/6/25 上午3:36, Segher Boessenkool wrote:
> > mode(__TI__) is just the more portable way of writing mode(TI), the
> > latter will not work if something #define's TI (you cannot do that with
> > __TI__, you
power10-fused_alu, power10-fused-vec, power10-fused-branch): New.
> Forgot to ask if ok to backport to GCC 11 since the new instruction types
> were backported.
Yes, this is okay to backport. Thanks!
Segher
/powerpc/float128-minmax.c: Adjust expected code for
> power10.
> * lib/target-supports.exp (check_effective_target_has_arch_pwr10):
> New target support.
Just "New." please.
> /* { dg-require-effective-target powerpc_p9vector_ok } */
Please try whether you can lose that line as well.
Okay for trunk, and for 11 after the usual soak. Thanks!
Segher
On Mon, Jun 28, 2021 at 03:00:02PM -0400, Michael Meissner wrote:
> On Wed, Jun 23, 2021 at 06:56:37PM -0500, Segher Boessenkool wrote:
> > > The problem area is a power10 running in
> > > big endian mode and running 32-bit code. Because we don't have TImode, we
>
|| (compare_mode == SFmode && result_mode == DFmode)
|| (compare_mode == DFmode && result_mode == SFmode)))
return false;
> +;; Support for ISA 3.1 IEEE 128-bit conditional move. The mode used in the
> +;; comparison must be the same as used in the conditional move.
s/conditional //
Okay for trunk with those fixes. Also okay for 11 after the usual wait.
Thanks!
Segher
ptr = gimple_call_arg (stmt, 2);
> + tree mem = build_simple_mem_ref (build2 (POINTER_PLUS_EXPR, TREE_TYPE
> (ptr), ptr, offset));
Same.
Can BU_MMA_LD be used only for lxvp? Name it BU_MMA_PAIR_LD then? Same
for _ST ofc.
The patch is okay for trunk. For the backports it is okay if Bill has
looked at this patch as well. Thanks!
Segher
'.file "lvsl-lvsr.c"'. */
Even better is to not put the instruction names in the filename, but
heh, maybe that would be too simple ;-)
Segher
On Thu, Nov 14, 2019 at 09:45:28AM +0300, Konstantin Kharlamov wrote:
> On Ср, ноя 13, 2019 at 15:23, Jason Merrill
> wrote:
> >On Wed, Nov 13, 2019 at 6:39 AM Segher Boessenkool
> > wrote:
> >> There are users. There are users who have been used to this
> >&
2601 - 2700 of 6091 matches
Mail list logo
