0, it will get the length, which in turn will get
> +;; num_insns and recurse).
> +(define_attr "length" "" (const_int 4))
Yes, and not only is it tempting, it is what we are going to do! Right?
:-) Just not just yet.
So please use a function for ADJUST_INSN_LENGTH. Okay for trunk like that.
Thanks! And sorry this took so long.
Segher
rands[1]);
> + DONE;}
> +
>[(set_attr "length" "8,8,8,12,12,8")
> (set_attr "max_prefixed_insns" "2")
> (set_attr "num_insns" "2,2,2,3,3,2")])
Newline before the } here, and no empty line after. Like all the rest ;-)
Okay with that fixed. Thanks!
Segher
s are available.
Okay for trunk. Thanks!
Segher
ntly do that, but it *could*. Or why not? The
compiler is always allowed to load 3 characters here, whether some string
has a NUL character earlier or not.
Segher
On Wed, Oct 23, 2019 at 06:46:14PM +0200, Jakub Jelinek wrote:
> On Wed, Oct 23, 2019 at 11:37:26AM -0500, Segher Boessenkool wrote:
> > On Wed, Oct 23, 2019 at 07:22:47PM +0300, Alexander Monakov wrote:
> > > On Wed, 23 Oct 2019, Eduard-Mihai Burtescu wrote:
> &g
On Wed, Oct 23, 2019 at 07:28:48PM +0200, Jakub Jelinek wrote:
> On Wed, Oct 23, 2019 at 12:19:10PM -0500, Segher Boessenkool wrote:
> > I of course know that for e.g. strcmp or strlen we need to be careful of
> > page crossings; but this is strncmp, which has a size argument sayi
On Wed, Oct 23, 2019 at 05:00:58PM -0400, Michael Meissner wrote:
> On Tue, Oct 22, 2019 at 05:27:19PM -0500, Segher Boessenkool wrote:
> > On Wed, Oct 16, 2019 at 09:35:33AM -0400, Michael Meissner wrote:
> > > - int n = get_attr_length (insn) / 4;
> > > + /* If the i
We already had those in fact, just under other names. Use the standard
names so that the vectorizer can use it.
Committing to trunk; will backport to 9 and 8 later.
Segher
2019-10-24 Segher Boessenkool
* config/rs6000/altivec.md (altivec_vavgu): Rename to...
(uavg3_ceil
a codesize and performance penalty.
> This applies to C code only, C++ code is not affected by -fcommon. It is
> about
> time to change the default.
Does this actually work on all older OSes (etc.) we support? Only one
way to find out, of course :-)
Segher
s "lwz" 3 } } */
> +/* { dg-final { scan-assembler-times "stw" 3 } } */
/* { dg-final { scan-assembler-times {\mlwz\M} 3 } } */
/* { dg-final { scan-assembler-times {\mstw\M} 3 } } */
so that it doesn't count when lwz or stw is only part of the word. This
doesn't so easily matter for scan-assembler-times, but still :-)
There also is some fallout in guality, but that's just showing the state
of guality.
So please fix those trivialities and explain why those two testcases need
a change, and it should be good to go. Nice patch Jiufu!
Segher
ake a test-run and see the size of the problem,
> but
>preferably once the stage#1 submisison and gcc-7 release cycles are done.
Yeah -- and if fallout is more than just testsuite, should it be postponed
to GCC 11? And announced now, etc.
But to find out we probably should flip the switch soon, see what happens,
only flip it back if necessary.
Segher
these extra moves are usually removed again: the
restore by cprop_hardreg, and then the save by rtl_dce.
Committing to trunk.
Segher
2019-10-26 Segher Boessenkool
PR target/91289
* config/rs6000/rs6000-logue.c (rs6000_emit_allocate_stack): Don't add
an immediate
; (see PR92046).
>
> A better patch would have been to adjust via the target hooks for
> unroll adjust.
So we should add target hooks for all params, to have them work sanely
with LTO?
What makes params special, different from normal command line options?
Segher
a few latent bugs. I'd expect there will be a few similar failures on
> other targets but nothing major since few testcases rely on -fcommon.
> The big question is how it affects the distros.
On what targets has it been bootstrapped (and tested)?
Segher
ormation about the
execution environment you're running on; why is this any better?
Segher
Hi!
On Wed, Oct 23, 2019 at 05:39:14PM +0800, Kewen.Lin wrote:
> I noticed that vsx_xvcdpsp and vsx_xvcvdpsp are almost the same,
> and vsx_xvcdpsp looks replaceable with vsx_xvcvdpsp since it's only
> called by gen_*.
Okay for trunk. Thanks!
Segher
> 2019
em.
>
> This patch is to update them with any_fix/any_float.
Okay for trunk. Thanks!
Segher
> 2019-10-23 Kewen Lin
>
> * config/rs6000/vsx.md (UNSPEC_VSX_CV[SU]XWSP,
> UNSPEC_VSX_XVCV[SU]XDDP, UNSPEC_VSX_XVCVDP[SU]XDS,
> UNSPEC_VSX_XVCVSPSXWS):
to only describe the defined parts (this works for e.g. mulhw
that describes its result as SImode: its DImode result has the high half
undefined).
> +;; Convert vector of 32-bit signed/unsigned integers to vector of
> +;; 64-bit floating point numbers.
> +(define_insn "vsx_xvcvxwdp_be"
> + [(set (match_operand:V2DF 0 "vsx_register_operand" "=wa")
> + (any_float:V2DF
> + (vec_select:V2SI (match_operand:V4SI 1 "vsx_register_operand" "wa")
> + (parallel [(const_int 0) (const_int 2)]]
> + "VECTOR_UNIT_VSX_P (V2DFmode) && BYTES_BIG_ENDIAN"
> + "xvcvxwdp %x0,%x1"
>[(set_attr "type" "vecdouble")])
This one for example is fine: words 1 and 3 of the input are unused, but
that is just fine.
Segher
On Tue, Oct 29, 2019 at 11:57:40PM +0100, Jakub Jelinek wrote:
> On Tue, Oct 29, 2019 at 05:40:11PM -0500, Segher Boessenkool wrote:
> > On Tue, Oct 29, 2019 at 06:15:31PM +0100, Jakub Jelinek wrote:
> > There already are a lot of different ways to get information about th
es(4).
> + And we may use PARAM to control kinds of loop size. */
That first line has no new information. So maybe something like
/* TODO: This is hardcoded to 10 right now. It can be refined, for
example we may want to unroll very small loops more times (4 perhaps).
We also should use a PARAM for this. */
Okay for trunk like that. Thanks!
Segher
t; /* { dg-final { scan-assembler-times "xxpermdi" 6 { target le } } } */
> /* { dg-final { scan-assembler-times "vspltisb" 2 } } */
This one, too.
(Also needs testing on BE btw -- it's often fine if you don't, but only
fixing the tests for LE isn't great ;-) )
Segher
Hi!
On Thu, Oct 31, 2019 at 10:19:49AM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> > On Wed, Oct 30, 2019 at 11:34:42AM +0800, Jiufu Guo wrote:
> >> In this patch, loop unroll adjust hook is introduced for powerpc. In this
> >> hook,
> >> we can do
... etc.,
> they have same issues. It looks more like a new issue to avoid that.
What does "artificially" mean? If you had to change the compiler for your
test, that doesn't count; otherwise, please file a PR.
> * config/rs6000/vsx.md (UNSPEC_VSX_CVSPSXDS, UNSPEC_VSX_CVSPUXDS):
> Remove.
(line too long)
Okay for trunk. Thanks!
Segher
st immediately before final,
one of the two that is run at -O0 as well).
It's great to always write "#" here, it is nice documentation ("this insn
is always split"), but you still need to get your split condition correct.
Segher
On Wed, Oct 23, 2019 at 04:42:19PM -0500, Segher Boessenkool wrote:
> On Wed, Oct 23, 2019 at 05:00:58PM -0400, Michael Meissner wrote:
> > On Tue, Oct 22, 2019 at 05:27:19PM -0500, Segher Boessenkool wrote:
> > > On Wed, Oct 16, 2019 at 09:35:33AM -0400, Michael Meissner wrote
ot;vint_operand")
> + (match_operator 1 "comparison_operator"
> + [(match_operand:VEC_I 2 "vint_operand")
> +(match_operand:VEC_I 3 "vint_operand")]))]
> + "VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode)"
> +{
> + emit_insn (gen_vec_cmp (operands[0], operands[1],
> + operands[2], operands[3]));
> + DONE;
> +})
unsigned_comparison_operator?
Why *are* there separate vec_cmp and vec_cmpu patterns, in the first place?
Segher
tring "20")]
> +
> + (const_string "12")))])
You can use const_int instead of const_string here, I think? Please do
that if it works.
Quite a simple expression, phew :-)
> + if (which_alternative == 0)
> +output_asm_insn ("xor. %3,%3,%4", operands);
> + else
> +output_asm_insn ("cmpld %0,%3,%4\;li %3,0", operands);
That doesn't work: the backslash is treated like the escape character, in
a C block. I think doubling it will work? Check the generated insn-output.c,
it should be translated to \t\n in there.
Okay for trunk with those things taken care of. Thanks!
Segher
return 2;
> + /* Like rs6000_insn_cost, make load insns cost a bit more. FIXME: the
> +benefits were observed on Power8 and up, we can unify it if similar
> +profits are measured on Power6 and Power7. */
> + if (TARGET_P8_VECTOR)
> + return 4;
> + else
> + return 2;
And this.
Segher
rs6000_function_specific_save (struct
> cl_target_option *ptr,
> {
>ptr->x_rs6000_isa_flags = opts->x_rs6000_isa_flags;
>ptr->x_rs6000_isa_flags_explicit = opts->x_rs6000_isa_flags_explicit;
> + ptr->x_unroll_small_loops = opts->x_unroll_small_loops;
> }
Yeah we shouldn't need to add that, this should all be automatic.
Segher
PR92090
PR other/92090
> * gcc.target/powerpc/pr72804.c: Likewie.
"Likewise."
Thanks!
Segher
On Sat, Oct 26, 2019 at 04:35:04PM +, Segher Boessenkool wrote:
> When we have -fstack-limit-symbol with sysv we can end up with a non-
> existing instruction (you cannot add an immediate to register 0). Fix
> this by using register 11 instead. It might be used for something else
On Thu, Oct 24, 2019 at 06:19:03PM +, Segher Boessenkool wrote:
> We already had those in fact, just under other names. Use the standard
> names so that the vectorizer can use it.
>
> Committing to trunk; will backport to 9 and 8 later.
I've done those backpo
The conbine pass is perfectly happy if a splitter splits to just one
instruction (instead of two).
Committing to trunk.
Segher
2019-11-05 Segher Boessenkool
* doc/md.texi (Insn Splitting): Fix combiner documentation.
---
gcc/doc/md.texi | 2 +-
1 file changed, 1 insertion(+), 1
This introduces simplify_logical_relational_operation. Currently the
only thing implemented it can simplify is the IOR of two CONDs of the
same arguments.
Tested on powerpc64-linux {-m32,-m64}.
Is this okay for trunk?
Segher
2018-11-06 Segher Boessenkool
* simplify-rtx.c
plemented.
Okay for trunk. Thanks!
Segher
> 2019-11-06 Kelvin Nilsen
>
> * config/rs6000/vsx.md (xxswapd_): Add support for V2DF and
> V2DI modes.
oad latency,
> it's possible to get worse result in the actual benchmarks based on my fine
> grain
> cost adjustment experiment before.
>
> Or do you suggest enabling it everywhere and solve the degradation issue if
> exposed?
> I'm also fine with that. :)
Yeah, let's just enable it everywhere.
Segher
icit?
Isn't it good and/or bad in all the same cases, implicit and explicit?
> +munroll-small-loops
> +Target Undocumented Var(unroll_small_loops) Init(0) Save
> +Use conservative small loop unrolling.
Undocumented means undocumented, so you don't have a comment string in
here. But you can comment it:
; Use conservative small loop unrolling.
Segher
were asking why not have one
> unique pattern for them?
Yes, it is redundant, the comparison code already says if it is an
unsigned comparison. So this a question about the generic patterns, not
your implementation of them :-)
And if it is *one* pattern then handling LTU etc. makes perfect sense.
> I noticed some vectorization related SPNs have
> separate signed and unsigned patterns, I guess it's due to that sign matters
> for some vector instructions, some platform may only support some of them,
> using sign for fine grain queries and checks?
I think it is because one particular implementation has different machine
insns for both, the one this interface was implemented for first.
> Updated patch attached by addressing above comments.
I'll review it later, sorry.
Segher
> +proc dg-require-target-object-format { args } {
> +if { [gcc_target_object_format] == [lindex $args 1] } {
> + return
> +}
"==" for strings is dangerous. Use "eq" or "string equal"?
Segher
value is currently ignored by the caller, but must be 0. */
> + return 0;
> +}
A temporary file like this isn't so great. Opening a file as "r" but then
accessing it with "fread" is peculiar, too.
HTH,
Segher
Hi!
On Thu, Nov 07, 2019 at 06:44:17PM +0100, Egeyar Bagcioglu wrote:
> On 11/7/19 9:03 AM, Segher Boessenkool wrote:
> >>+ ASM_OUTPUT_ASCII(asm_out_file, cmdline, cmdline_length);
> >>+}
> >>+ cmdline[0] = 0;
> >>+ ASM_OUTPUT_ASCII(asm_out_file,
On Wed, Nov 06, 2019 at 10:46:06AM -0700, Jeff Law wrote:
> BTW, I think there's enough overlap between simplify-rtx and combine
> that if you wanted to maintain simplify-rtx as well that I'd fully
> support it. Thoughts?
I'd be honoured, thanks for the offer!
Segher
seems reasonable to you and works well in your
tests: approved for trunk. Thanks!
Segher
step. And broke the powerpc bootstraps now.
So sorry.
It failed in stage 1 before, it's still building but past there, so I'll
commit this now.
Segher
2019-11-07 Segher Boessenkool
* config/rs6000/rs6000.c (validate_condition_mode): Don't assert for
valid c
Hi!
On Thu, Nov 07, 2019 at 06:17:53PM +0800, Kewen.Lin wrote:
> on 2019/11/7 上午7:49, Segher Boessenkool wrote:
> > The expander named "one_cmpl3":
> >
> > Erm. 2, not 3 :-)
> Ah, sorry I didn't notice we have one cmpl**3** but actually for one
>
Another part I forgot yesterday. With this, everything is back to
normal.
Committing.
Segher
2019-11-08 Segher Boessenkool
* config/rs6000/predicates.md (branch_comparison_operator): Allow only
the comparison codes that make sense for the mode used, and only the
want to unroll very small loops more times (4 perhaps).
> + We also should use a PARAM for this. */
There will be target-specific params soon, if I understood correctly :-)
Cheers,
Segher
On Fri, Nov 08, 2019 at 12:05:19AM +0100, Egeyar Bagcioglu wrote:
> On 11/7/19 7:57 PM, Segher Boessenkool wrote:
> >>>Opening a file as "r" but then
> >>>accessing it with "fread" is peculiar, too.
> >>I am not sure what you mean here. Is it
erand")]))]
you can do
[(set (match_operand:VEC_I 0 "vint_operand")
(some_iter:VEC_I (match_operand:VEC_I 1 "vint_operand")
(match_operand:VEC_I 2 "vint_operand")))]
with some_iter some code_iterator, (note you need to renumber), and in the
body you can then just use (or , or some other code_attribute).
code_iterator is more flexible than match_operator, in most ways.
Segher
On Sun, Nov 10, 2019 at 01:32:29AM -0500, Michael Meissner wrote:
> On Fri, Nov 01, 2019 at 10:22:03PM -0500, Segher Boessenkool wrote:
> > On Wed, Oct 16, 2019 at 09:47:41AM -0400, Michael Meissner wrote:
> > We could make %pN mean 'p' for prefixed, for memory as operand
On Sun, Nov 10, 2019 at 12:38:56AM -0600, Segher Boessenkool wrote:
> It emits a literal ';' into the assembler code.
Or actually, huh, it doesn't. Sorry. See read_braced_string in
read-md.c . Your code is fine.
Segher
Sometimes combine wants to do a move in CCFPmode, but we don't currently
handle moves in any CC mode other than CCmode. Fix that oversight.
Tested on powerpc64-linux {-m32,-m64}. Committing to trunk.
Segher
2019-11-10 Segher Boessenkool
* config/rs6000/rs6000.md (CC_any)
Hi Alan,
On Mon, Nov 11, 2019 at 05:46:01PM +1030, Alan Modra wrote:
> On Wed, Aug 21, 2019 at 09:55:28PM +0930, Alan Modra wrote:
> > On Mon, Aug 19, 2019 at 07:45:19AM -0500, Segher Boessenkool wrote:
> > > But if you think we can remove the !TARGET_TLS_MARKERS everywhere it
(match_operand:P 2 "gpc_reg_operand" "b")]
> UNSPEC_TLSGD))]
> - "HAVE_AS_TLS && TARGET_TLS_MARKERS"
> + "HAVE_AS_TLS && !TARGET_XCOFF"
Should that be TARGET_ELF instead?
Okay for trunk with those two things looked at. Thanks!
Segher
ed/uneq/ltgt and adding ungt/unge/unlt/unle/
> ne. As Segher pointed out, some patterns can be refactored
> together. The main link on this is:
> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00452.html
>
>
> The refactoring mainly follows the below patterns:
>
> pattern
t this,
the !HONOR_NANS code is very close to the integer code, so it's not all
that bad.
Assert... Should we have an assert in some strategic places that makes
sure we never try to create NaN stuff when NaNs are disabled?
Segher
-Ofast with -fno-cx-limited-range.
> The following patch makes sure we don't emit it even in that case.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> I'll defer the addition of the testcase and rs6000 changes to Segher.
Thanks for doing this.
thread_jumps?
It may be a good idea to throw away the dom info anyway, but the comment
seems off then?
Segher
2019-11-12 Segher Boessenkool
gcc/testsuite/
* gcc.c-torture/compile/pr92449.c: New test.
* gcc.target/powerpc/pr92449-1.c: New test.
---
gcc/testsuite/gcc.c-torture/compile/pr92449.c | 7 +++
gcc/testsuite/gcc.target/powerpc/pr92449-1.c | 7 +++
2 files changed, 14
that
Jakub fixed earlier.
Tested on powerpc64-linux {-m32,-m64}. Cmmitting to trunk.
Segher
gcc/config/rs6000/vsx.md | 12
gcc/testsuite/gcc.c-torture/compile/pr92449.c | 7 +++
gcc/testsuite/gcc.target/powerpc/pr92449-1.c | 7 +++
3 files changed
2019-11-12 Segher Boessenkool
* config/rs6000/vsx.md (xscmpexpdp_ for CMP_TEST): Handle
UNORDERED if !HONOR_NANS (DFmode).
(xscmpexpqp__ for CMP_TEST and IEEE128): Handle UNORDERED
if !HONOR_NANS (mode).
---
gcc/config/rs6000/vsx.md | 12
1 file
C++98 does not have long long int, and does not use (unsigned) long
long int for hexadecimal literals. So let's use an ULL suffix here,
which is still not strict C++98, but which works with more compilers.
Tested etc.; committing to trunk.
Segher
2019-11-12 Segher Boesse
is fine, okay for trunk, thanks!
Could you add a comment to the testcase saying what it is trying to test
exactly? It wasn't obvious to me. Just one or two lines is fine.
Segher
On Wed, Nov 13, 2019 at 09:15:38AM +0100, Richard Henderson wrote:
> On 11/12/19 10:52 PM, Segher Boessenkool wrote:
> > C++98 does not have long long int, and does not use (unsigned) long
> > long int for hexadecimal literals. So let's use an ULL suffix here,
> > which
t.in (pr, prl, pt, pct, pgg, pgq, pgs, pge, pmz, pdd, pbs, pbm):
Use "call" instead of "set".
Looks good to me otherwise, thanks! (This is not an approval, I am not
maintainer of this part of GCC).
Segher
ess nice.
It would be great if you could come up with something that keeps the
old syntax working as well, especially since many of us have to work
with older versions of the gdbinit as well, for years to come. People
can adjust their work habits of course, but that causes a lot of
friction ;-)
Segher
t; {
> 0, 1, 28, 2, 29, 14, 24, 3, 30, 22, 20, 15, 25, 17, 4, 8,
> 31, 27, 13, 23, 21, 19, 16, 7, 26, 12, 18, 6, 11, 5, 10, 9
> };
>
> return table[((unsigned)((x & -x) * 0x077CB531U)) >> 27];
> }
Out of interest, what uses this? I have never seen it before.
Segher
Hi!
On Tue, Nov 12, 2019 at 04:32:36PM +0100, Ilya Leoshkevich wrote:
> > Am 12.11.2019 um 15:32 schrieb Segher Boessenkool
> > :
> > On Tue, Nov 12, 2019 at 03:11:05PM +0100, Ilya Leoshkevich wrote:
> >> unsigned int
> >> pass_jump_after_combine::execute
ux-gnu).
I wonder why that test was there. It was added in r84513, which is where
insn_rtx_cost was made from combine_insn_cost, which didn't have that
non-jump thing yet.
It is still stage 1, so we'll find out if any target breaks I guess.
Okay for trunk. Thanks!
Segher
fixed
that up manually. But then I hit
during RTL pass: jump2
/home/segher/src/kernel/fs/binfmt_elf.c: In function 'elf_core_dump':
/home/segher/src/kernel/fs/binfmt_elf.c:2409:1: internal compiler error: in
patch_jump_insn, at cfgrtl.c:1290
0x102c3c2f patch_jump_insn
/home/segh
On Wed, Nov 13, 2019 at 07:57:58PM +0100, Bernd Schmidt wrote:
> On 11/13/19 7:16 PM, Segher Boessenkool wrote:
> > I tried this out with a kernel build (just the defconfig).
>
> > during RTL pass: jump2
> > /home/segher/src/kernel/fs/binfmt_elf.c: In function 'elf
Hi!
On Sun, Nov 01, 2020 at 06:32:02PM -0500, Vladimir Makarov wrote:
> On 2020-10-30 7:36 p.m., Segher Boessenkool wrote:
> >Thanks for the patch! But it has a problem:
> >
> >>diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
> >>index 67e4f2fd
On Mon, Nov 02, 2020 at 11:18:00AM -0500, Vladimir Makarov wrote:
> On 2020-11-02 6:43 a.m., Segher Boessenkool wrote:
> >(Should "*" be changed so that it skips a whole constraint if it can,
> >instead of only a single char always?)
> >
> Yes, it should be chan
On Mon, Nov 02, 2020 at 10:28:44AM -0600, Segher Boessenkool wrote:
> On Mon, Nov 02, 2020 at 11:18:00AM -0500, Vladimir Makarov wrote:
> > On 2020-11-02 6:43 a.m., Segher Boessenkool wrote:
> > >(Should "*" be changed so that it skips a whole constraint if it can,
&
!= REG_PARM_STACK_SPACE (current_function_decl)))
Please don't use superfluous parens, like (a) || (b) here, it makes
things harder to read than necessary.
Other than that this patch is fine. Thanks!
Segher
all. */
> if (REG_PARM_STACK_SPACE (decl ? decl : fntype)
> > INCOMING_REG_PARM_STACK_SPACE (current_function_decl))
>
> and note the change to use INCOMING_REG_PARM_STACK_SPACE.
> Bootstrapped and regression tested powerpc64le-linux and biarch
> powerpc64-linux. OK?
Yes pl
On Fri, Oct 30, 2020 at 10:52:55PM -0400, Michael Meissner wrote:
> On Fri, Oct 30, 2020 at 06:39:16PM -0500, Segher Boessenkool wrote:
> > On Fri, Oct 30, 2020 at 06:50:30PM -0400, Michael Meissner wrote:
> > > On Fri, Oct 30, 2020 at 03:54:06PM -0500, Segher Boessenkool wrote:
Hi Joseph,
On Thu, Oct 29, 2020 at 10:05:38PM +, Joseph Myers wrote:
> On Thu, 29 Oct 2020, Segher Boessenkool wrote:
> > > Doing these conversions accurately is nontrivial. Converting via strings
> > > is the simple approach (i.e. the one that moves the complexity
do the f128 functions work in the other cases? *Do* they?
Segher
__ibm128) 1.79769313486231580793728971405301199e+308L)
>
> #elif defined(__LONG_DOUBLE_IBM128__)
> #define LDOUBLE long double
> +#define IBM128_MAX LDBL_MAX
Can you define this in such a way that it always works?
Segher
On Tue, Nov 03, 2020 at 01:12:29AM +, Joseph Myers wrote:
> On Mon, 2 Nov 2020, Segher Boessenkool wrote:
>
> > > Also note that if you want to use printf as opposed to strfromf128 for
> > > IEEE binary128 you'll need to use __printfieee128 (the version that
&g
@@ -0,0 +1,14 @@
> +/* { dg-do compile { target { lp64 && has_arch_pwr9 } } } */
> +/* { dg-require-effective-target powerpc_p9vector_ok } */
> +/* { dg-options "-O2" } */
As David said:
/* { dg-do compile } */
/* { dg-require-effective-target lp64 } */
/* { dg-require-effective-target has_arch_pwr9 } */
/* { dg-require-effective-target powerpc_p9vector_ok } */
/* { dg-options "-O2 -mdejagnu-cpu=power9" } */
But, you probably don't want that has_arch_pwr9 line at all, this is a
compile test?
> +/* { dg-final { scan-assembler-not {\mstb\M} } } */
> +/* { dg-final { scan-assembler-not {\msth\M} } } */
Btw, if this didn't for -mcpu=power9, you probably would need to allow
prefixed stores here, like {\mp?stb\M} .
So, okay for trunk with those TARGET_POWERPC64 fixed, and that one
remaining testcase. Thanks!
Segher
d make that
/* { dg-do compile } */
at the same time, if you want? If that is easy for you, don't bother
otherwise.
Segher
I'll ping it myself then!
Segher
On Thu, Oct 22, 2020 at 06:03:46PM -0400, Michael Meissner wrote:
> PowerPC: Map IEEE 128-bit long double built-in functions
>
> This patch is revised from the first and second versions of the patch posted.
> It now uses the names that are
Self-ping.
Mike, can you reply to Alan's mail please? He makes a lot of points,
not all of them bad certainly!
Segher
On Wed, Oct 28, 2020 at 08:42:04PM -0400, Michael Meissner wrote:
> PowerPC: PR libgcc/97543, fix 64-bit long double issues
>
> There are two issues in PR libg
at's a fundamental restriction of the target and the
> tests should just be skipped or (b) the target needs to implement
> the new hook.
But why are tests in gcc.target/i386/ run for other targets at all?!
Segher
{
> /* ... */
> (p->ld)++;
> /* ... */
> }
>
> On a power9/10 system with IEEE long double or on a system with a 64-bit long
> double, that code would not generate a call, but it does depend on the long
> double format (and hence should set the gnu attribute #4).
Yes, but setting it for any DFmode (with 64-bit long double) is just
wrong.
Segher
On Wed, Nov 04, 2020 at 01:58:26PM -0600, Qing Zhao wrote:
> > On Nov 4, 2020, at 1:00 PM, Segher Boessenkool
> > wrote:
> > On Wed, Nov 04, 2020 at 01:20:58PM +, Richard Sandiford wrote:
> >> Tobias Burnus writes:
> >>> Three of the testcases fail
is hard to detect
whether you have a new enough glibc though :-/
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/float128-longdouble-stdio.c
> @@ -0,0 +1,37 @@
> +/* { dg-require-effective-target ppc_float128_hw } */
> +/* { dg-require-effective-target power10_ok } */
> +/* { dg-options "-mdejagnu-cpu=power9 -mno-pcrel -O2 -Wno-psabi
> -mabi=ieeelongdouble" } */
Same power10_ok issue as the other test.
Segher
flag is automatically not enabled by default on targets that
do not handle this correctly.
This patch fixes it.
Segher
2020-11-06 Segher Boessenkool
PR target/96933
* config/rs6000/rs6000.c (rs6000_expand_vector_init): Use
TARGET_POWERPC64 instead of TARGET_64BIT
uilt-ins.
> + Since the test below doesn't need any other MMA support, we can enable
> + this test case on basically any cpu that has hard floating point
> + registers. */
Good comment, thanks :-) That "basically" does not sound super
convincing, but this is just a testcase, we can fix it later if need be.
Segher
simplifies the code
a tiny bit as well.
2020-11-06 Segher Boessenkool
* config/rs6000/rs6000.md (@tablejump_normal): Don't abuse
operands[].
(@tablejump_nospec): Ditto.
---
gcc/config/rs6000/rs6000.md | 18 ++
1 file changed, 6 insertions(+), 12 dele
On Fri, Nov 06, 2020 at 11:45:21PM -0500, Michael Meissner wrote:
> On Mon, Nov 02, 2020 at 07:00:15PM -0600, Segher Boessenkool wrote:
> > > + /* This test is written to test IBM extended double, which is a pair of
> > > + doubles. If long double can hold a larger va
but not for PREFIXED_NO or PREFIXED_ALWAYS.
Another way to do this is to do like maybe_var_shift does: things you
mask maybe_prefixed=yes get their prefixed attribute set to no or yes
depending on their operands, and for things where we always want to
set the prefixed attribute we can do just that. I don't know what reads
better / is more clear, and/or is more work to write (the schemes are
semantically identical).
Segher
TPUT_OPCODE emits a leading 'p'
> for
> +;; prefixed="yes" insns. The default "length" attribute will also be
> adjusted
> +;; by default to be 12 bytes.
In xxspltiw it is only 32 bits, not 34. This comment really only
describes the 8LS-form prefix insns.
> @@ -2517,7 +2517,7 @@ (define_insn "pextd"
> UNSPEC_PEXTD))]
> "TARGET_POWER10 && TARGET_POWERPC64"
> "pextd %0,%1,%2"
> - [(set_attr "type" "integer")])
> + [(set_attr "type" "crypto")])
Same as above, but for integer instead of vector.
> (define_insn "bswapdi2_reg"
> @@ -5242,7 +5242,7 @@ (define_insn "setbc_signed_"
>(const_int 0)]))]
>"TARGET_POWER10"
>"setbc %0,%j1"
> - [(set_attr "type" "isel")])
> + [(set_attr "type" "integer")])
Why? Are these insns executed differently than the isel insn? They do
take a CR field as input, which none of the integer isns do.
> --- a/gcc/config/rs6000/vsx.md
> +++ b/gcc/config/rs6000/vsx.md
> @@ -2032,7 +2032,7 @@ (define_insn "*xvtlsbb_internal"
>UNSPEC_XVTLSBB))]
>"TARGET_POWER10"
>"xvtlsbb %0,%x1"
> - [(set_attr "type" "logical")])
> + [(set_attr "type" "veccmp")])
Yup.
Maybe split the patch into a few themes? Some themes are much easier
than others to review, are much more obvious; and they are all
independent anyway?
Segher
I+0x1])
6: r125:SI=zero_extend([r123:DI])
8: r127:SI=r125:SI+r126:SI
9: r124:DI=sign_extend(r127:SI)
8+9 is combined to just
9: r124:DI=r125:DI+r126:DI
and that's all? (The "compact" format leaves out crucial information,
but the loads here are QImode loads.)
I don't think 4->3 combines will do very much that cannot be done by
some combination of 2->1, 3->1, 4->1, 2->2, 3->2, 4->2, but we'll see.
It will be quite expensive to do in any case (combine isn't one of the
expensive passes anymore, but let's try to keep it that way ;-) )
Segher
On Wed, Nov 11, 2020 at 06:22:53PM -0600, Segher Boessenkool wrote:
> I'm running an all-arch comparison with this patch, just to see what it
> does, but [...]
Results: C0 is trunk, C1 with patch:
C0C1
alpha 6422312 99.971%
arc 37838
ble, which is bound to hard reg fr1 rather than the asm statements
> themselves. It's not clear to me from the BZ and I don't have a PPC
> cross handy to look directly.
We should never do a reload of a (local) register variable.
Unfortunately we cannot currently tell during reload that something is
one!
See also PR97708, and many more, going many years back.
Segher
uld work as well! Did you
see failures without this patch? Thos need fixing, then.
Segher
On Thu, Nov 12, 2020 at 04:44:09PM -0500, Michael Meissner wrote:
> On Thu, Nov 12, 2020 at 01:26:32PM -0600, Segher Boessenkool wrote:
> > On Thu, Oct 22, 2020 at 06:12:31PM -0400, Michael Meissner wrote:
> > > Two of the tests used the __ieee128 keyword instead of __float128.
801 - 900 of 6091 matches
Mail list logo
