On Thu, Feb 13, 2020 at 08:48:33AM +0100, Richard Biener wrote:
> On Wed, 12 Feb 2020, Segher Boessenkool wrote:
> > On Wed, Feb 12, 2020 at 11:53:22AM +0100, Richard Biener wrote:
> > > BB reorder switches back and forth as well ... :/
> >
> > Yes. It is extreme
} */
Just like this one. Do they match 0 times now? Please keep the entry
then, but for 0 times?
Okay for trunk with that taken care of whichever way. Thanks!
Segher
dg-final { scan-tree-dump-times "LOOP VECTORIZED" 14 "vect" } } */
> +/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 14 "vect" { target
> p8vector_hw } } } */
That actually checks if the hardware is p8 or later, while what you care
about is what options are compiled with. Say, if running on a p8 but
compiling for a p7 this will fail?
Segher
From: Matheus Castanho
Some system headers can be broken by the machine_name fix performed
by GCC during the fixincludes step. According to the comment in
fixincludes/fixinc.h:130 :
On some platforms, machine_name doesn't work properly and
breaks some of the header files. Since everything
On Fri, Feb 14, 2020 at 02:58:49PM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
>
> > On Sat, Feb 08, 2020 at 10:17:42AM -0600, Segher Boessenkool wrote:
> >> And we do not know which of the register will be used for the return, in
> >> untyped_call (only
Hi!
On Fri, Feb 14, 2020 at 10:34:40AM -0800, Mike Stump wrote:
> On Feb 4, 2020, at 9:40 AM, Segher Boessenkool
> wrote:
> >> My intent is to make adding new built-in functions as simple as adding
> >> a few lines to a couple of files, and automatically genera
in order to avoid having a function whose
> body is empty.
Please Cc: the rs6000 maintainers on rs6000 patches, you will get a
reply faster, and more reliably.
Please don't use binary attachments, it takes effort to reply to those.
Segher
it format-patch? You should, as the manual pages for both
git imap-send and git send-email explain.
> Will try pasting the .patch inline as plain text and see if that works.
That doesn't work, unless you take extreme care. It is fine for showing
small snippets, but it does not result in patches people can apply.
Segher
ly not allow anything else than bit patterns, not
floating point constants, have a separate pattern for that (that can
then forward to the integer one).
> This way we have just one place that centralizes the knowledge about the
> instruction.
That one place should be the define_insn for it.
Segher
;movsf_hardfloat"
> @@ -8051,20 +8057,21 @@ (define_insn "*mov_hardfloat32"
> @@ -8091,19 +8098,19 @@ (define_insn "*mov_softfloat32"
> @@ -8125,18 +8132,19 @@ (define_insn "*mov_hardfloat64"
> @@ -8170,6 +8178,7 @@ (define_insn "*mov_softfloat64"
It would be a good idea to merge many of these patterns again. We can
do this now that we have the "isa" and "enabled" attributes.
Segher
nformation for inlinable always_inline functions.
> */
> + bool scan_for_target_info =
> +(info->inlinable
> + && DECL_DISREGARD_INLINE_LIMITS (node->decl)
> + && lookup_attribute ("always_inline", DECL_ATTRIBUTES (node->decl))
> + && targetm.target_option.need_ipa_fn_target_info (node->decl,
> +info->target_info));
Don't use unnecessary parens please.
Segher
ys why it can
not be done yet).
Segher
On Wed, Sep 01, 2021 at 04:22:13PM -0400, Michael Meissner wrote:
> On Tue, Aug 31, 2021 at 06:41:30PM -0500, Segher Boessenkool wrote:
> > Hi!
> >
> > Please do two separate patches. The first that adds the instruction
> > (with a bit pattern, i.e. integer, input), a
. So here goes.
Segher
2021-09-03 Segher Boessenkool
PR target/102107
* config/rs6000/rs6000-logue.c (rs6000_emit_prologue): On ELFv2 use r11
instead of r12 for CR save, in all cases.
---
gcc/config/rs6000/rs6000-logue.c | 11 +++
1 file changed, 7 insertions
/
These are negative tests, so won't spuriously fail, but this does not
test for the function prefixes we can have. See
gcc.target/powerpc/builtins-1.c for example.
Again, thank you, and thanks to everyone else for the patch review
action :-)
Segher
s well as in other code that handles
subregs). I doubt this is possible to do, subreg have so many
overloaded meanings already.
Segher
hich
> would also have poorly defined semantics. Perhaps your interpretation of
> the
> RTL documentation doesn't strictly apply to this part of the RTL optimizers?
Perhaps this is a bug. It is if it actually allows subregs of ints as
input.
Segher
Hi!
On Mon, Sep 06, 2021 at 04:59:27PM +0800, Xionghu Luo wrote:
> On 2021/9/4 05:44, Segher Boessenkool wrote:
> >>+/* { dg-final { scan-assembler-not {\mbl fmod\M} } } */
> >>+/* { dg-final { scan-assembler-not {\mbl fmodf\M} } } */
> >>+/* { dg-final { scan-a
c anyway. Just
write
/* { dg-do compile } */
and nothing more (this (compile) is the default as well, you can just
leave it out completely if you want).
Finally: should whatever the old code generated have been optimised
better?
Segher
ings to become unexpected (although it meets
> the basic rule, not so elegant), sigh.
It has too many parens, making grouping where there is none, that is the
core issue.
if (kind == vec_to_scalar
|| kind == vec_perm
|| kind == vec_promote_demote
|| kind == vec_construct
|| kind == scalar_to_vec
|| (kind == vector_stmt && where == vect_body))
Segher
n_movsf_from_si (dest, tmp));
> + return true;
> + }
This makes it two separate insns. Is that always optimised to code that
is at least as good as before?
Segher
On Fri, Sep 03, 2021 at 05:05:47PM +0200, Andreas Schwab wrote:
> On Sep 02 2021, Segher Boessenkool wrote:
> > On Tue, Aug 31, 2021 at 07:17:49PM +0800, liuhongt via Gcc-patches wrote:
> >>* emit-rtl.c (validate_subreg): Get rid of all float-int
> >>special
We cannot use r12 here, it is already in use as the GEP (for sibling
calls).
Committed to trunk. Will backport later, too.
Segher
2021-09-08 Segher Boessenkool
PR target/102107
* config/rs6000/rs6000-logue.c (rs6000_emit_epilogue): For ELFv2 use
r11 instead of r12
Hi!
On Wed, Sep 08, 2021 at 08:42:44AM +0200, Richard Biener wrote:
> On Wed, Sep 8, 2021 at 1:08 AM Segher Boessenkool
> wrote:
> > The core of the problem is that subreg of pseudos has three meanings:
> > -- Paradoxical subregs;
> > -- Actual subregs;
> >
On Wed, Sep 08, 2021 at 08:39:31PM +0200, Richard Biener wrote:
> On September 8, 2021 7:08:09 PM GMT+02:00, Segher Boessenkool
> wrote:
> >It is not a good idea to do allow all those things. Most backends can
> >only support a few combinations of them, and everything else re
const unsigned int MAX_PENALIZED_COST_FOR_CTOR = 12;
> + if (extra_cost > MAX_PENALIZED_COST_FOR_CTOR)
> + extra_cost = MAX_PENALIZED_COST_FOR_CTOR;
That is a pretty gross hack. Can you think of any saner way to not have
those out of scale costs in the first place?
Okay for trunk with such tweaks. Thanks! (And please consult with Bill
for the wordsmithing :-) )
Segher
Hi!
On Thu, Sep 09, 2021 at 12:19:28PM -0500, Bill Schmidt wrote:
> On 9/9/21 11:11 AM, Segher Boessenkool wrote:
> >On Wed, Sep 08, 2021 at 02:57:14PM +0800, Kewen.Lin wrote:
> >>+ /* If we have strided or elementwise loads into a vector, it's
> >"stri
rom that same history it follows that anything you
do not super carefully (with testing everywhere) will cause some serious
problems. And nonse of these are easy to fix at all -- there is a
*reason* targets did this nastiness.
> > p.s. Very unrelated... Should we have __builtin_bit_cast for C as well?
> > Is there any reason this could not work?
Still interested in this btw :-) (And still very unrelated.)
Segher
ode @var{n}). Both modes must be fixed
point or both floating point.
TRULY_NOOP_TRUNCATION does not make sense to ask if changing mode class.
Segher
On Fri, Sep 10, 2021 at 12:53:37PM +0200, Richard Biener wrote:
> On Fri, Sep 10, 2021 at 1:50 AM Segher Boessenkool
> wrote:
> > And many targets have strange rules for bit-strings in which modes can
> > be used as bit-strings in which other modes, and at what offsets in
&
On Fri, Sep 10, 2021 at 11:09:31AM +0800, Hongtao Liu wrote:
> On Fri, Sep 10, 2021 at 7:49 AM Segher Boessenkool
> wrote:
> > way too long. But from that same history it follows that anything you
> > do not super carefully (with testing everywhere) will cause some serious
On Fri, Sep 10, 2021 at 03:58:47PM +0200, Richard Biener wrote:
> On September 10, 2021 3:30:10 PM GMT+02:00, Segher Boessenkool
> wrote:
> >TRULY_NOOP_TRUNCATION does not make sense to ask if changing mode class.
>
> OK, so there's a mode class comparison missing here w
ave to* use attachments,
use text attachments. Without encoding.
<https://gcc.gnu.org/contribute.html#patches>
(It says "strongly discouraged", which means people will put it to the
bottom of the stack of things to look at).
Segher
On Fri, Sep 10, 2021 at 08:36:12PM +0200, Richard Biener wrote:
> On September 10, 2021 6:24:50 PM GMT+02:00, Segher Boessenkool
> wrote:
> >Yes, we should not call TRULY_NOOP_TRUNCATION_MODES_P for any random two
> >modes: such a truncation needs to have a meaning at all, for
er constants in XOmode so we wrap this in an UNSPEC.
Does the comment need updating? It may help to point out here that itr
needs to be volatile.
> (set_attr "length" "4")])
Not new of course: the default length is 4, most insns have that, it
helps to be less verbose.
Okay for trunk with that changelog fix. Thanks!
Segher
s is the only good reason for
> splitting this into two patterns; you need different criteria.)
The *good* reason for splitting the pattern is they have completely
different expansions as well. Which is why I asked for it.
(I'll review the patch later).
Segher
On Mon, Sep 13, 2021 at 02:42:10PM +0800, Kewen.Lin wrote:
> This patch follows Segher's suggestion here[1] to get rid of
> the typedef, it's pre-approved as [1].
Thanks!
Segher
turn TARGET_MMA;
> +}
> + gcc_unreachable ();
> +}
Could you put all the CPU ones together (except maybe Cell)? The really
mean architecture version, and they should be renamed some day perhaps
(the TARGET_ names that is). It now is some kind of revisionist
historical order :-)
> --- a/gcc/config/rs6000/rs6000-gen-builtins.c
> +++ b/gcc/config/rs6000/rs6000-gen-builtins.c
> @@ -2314,7 +2314,7 @@ write_decls (void)
>
>fprintf (header_file, "extern void rs6000_init_generated_builtins
> ();\n\n");
>fprintf (header_file,
> -"extern bool rs6000_new_builtin_is_supported_p "
> +"extern bool rs6000_new_builtin_is_supported "
> "(rs6000_gen_builtins);\n");
This now fits on one line, too :-)
Okay for trunk with the trivial things fixed. And everythin else needs
to be fixed later still.
Thanks!
Segher
needs to be volatile.
>
> I think the comment was referring to the unneeded operand which I have
> now removed. I could either remove the comment altogether or change it
> to:
>
> ;; We can't have integer constants in XOmode so we wrap this in an
> ;; UNSPEC_VOLATILE.
>
> ...to refer to the dummy zero for the source. Let me know what you want.
No strong opinion, the existing comment looked out of place, that's all.
The latter option adds information, so if you think that is useful to
have here, let's go with that?
Cheers,
Segher
"altivec_register_operand" "wa,v"))
>(and:VM
> - (match_operand:VM 2 "altivec_register_operand" "v")
> - (match_operand:VM 4 "altivec_register_operand" "v"]
> + (match_operand:VM 2 "altivec_register_operand" "wa,v")
> + (match_operand:VM 4 "altivec_register_operand" "wa,v"]
>"VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode)
>&& rtx_equal_p (operands[2], operands[3])"
> - "vsel %0,%1,%4,%3"
> + "@
> + xxsel %x0,%x1,%x4,%x3
> + vsel %0,%1,%4,%3"
The mnemonics should align with the @.
This ordering makes us prefer xxsel over vsel. Do we want that? We
probably do, but it is a change I think?
Do we want to add an "isa" attribute? Most patterns still don't, but we
probably should wherever we can.
"altivec_register_operand" is wrong. Just "gpc_reg_operand" I think?
Segher
r changelogs.
> -rs6000-gen-builtins: rs6000-gen-builtins.o rbtree.o
> +build/rs6000-gen-builtins$(build_exeext): build/rs6000-gen-builtins.o
> build/rbtree.o $(BUILD_LIBDEPS)
Maybe break the prerequisites here (with "\"), the line is very long now?
Okay for trunk. Thanks!
Segher
o arrange things better?
Anyway: okay for trunk. Thanks!
Segher
ns are at 80 chars, not 72.
Okay for trunk (w/ the fixes from Will's review). Thanks!
Segher
lace_with_seq (gsi, new_seq, true);
> + return true;
> +}
Fwiw, all those cases return, so those "else" are not needed. Also it
would be nice if this could be factored a bit better, hrm.
Is that "if" in there useful? Maybe add a helper function for it, then?
Anyway: okay for trunk. Thanks!
Segher
e (or not worse than what there
already was, anyway ;-) ). So put this on the big "one day we will
clean this up" list?
Okay for trunk. Thanks!
Segher
_ipa_fn_target_info (uint16_t &, const gimple *)
I'm surprised the compiler didn't warn about this btw.
The rs6000 parts are okay for trunk (with the trivial cleanups please).
Thanks!
Segher
ee this, either.
A magic crazy formula like this is no good. If you want to make the
cost of everything but V2D* be the same, and that of V2D* be twice that,
that is a weird heuristic, but we can live with that perhaps. But that
beats completely unexplained (and unexplainable) magic!
Sorry.
Segher
It is a percentage. (0,100) is the maximum that makes any sense :-)
It may be useful to make it a bit more sensitive than hundreds, but it
is a heuristic anyway, this will work fine.
But allowing 100 will be good.
Segher
Hi!
On Wed, Sep 15, 2021 at 04:52:49PM +0800, Kewen.Lin wrote:
> This patch follows the discussion here[1], where Segher suggested
> parameterizing those exact magic constants for density heuristics,
> to make it easier to tweak if need.
>
> Since these heuristics are quite i
Hi!
On Sun, Sep 19, 2021 at 09:14:55AM -0600, Jeff Law wrote:
> On 9/6/2021 8:24 AM, Segher Boessenkool wrote:
> >On Mon, Sep 06, 2021 at 12:32:13PM +0100, Roger Sayle wrote:
> >>I think the current documentation is sufficient. During compilation,
> >>GCC&#x
Hi!
On Tue, Sep 21, 2021 at 01:47:19PM +0800, Kewen.Lin wrote:
> on 2021/9/18 上午6:26, Segher Boessenkool wrote:
> >> + if (data->nloads > (unsigned int) rs6000_density_load_num_threshold
> >> +&& load_pct > (unsigned int) rs6000_density_load_pct_t
On Mon, Sep 20, 2021 at 10:18:15PM -0600, Jeff Law wrote:
> On 9/20/2021 6:23 PM, Segher Boessenkool wrote:
> >There is no such thing as "earlier than simplify-rtx", that is the
> >point. simplify-rtx is not a pass: it is like a library that is used
> >from a
(aka we're combining on the fly).
>
> It's a bit like fold_convert (double_type_node, integer_one_node)
> second-guessing and doing a FLOAT_EXPR when folding
> the implicit CONVERT_EXPR.
Yeah :-/
Segher
Hi!
On Tue, Sep 21, 2021 at 11:24:08AM +0800, Kewen.Lin wrote:
> on 2021/9/18 上午6:01, Segher Boessenkool wrote:
> > On Thu, Sep 16, 2021 at 09:14:15AM +0800, Kewen.Lin wrote:
> >> The way with nunits * stmt_cost can get one much exaggerated
> >> penalized cost, such a
// { dg-message "parameter passing for an argument
> containing zero-width bit fields but that is otherwise a homogeneous
> aggregate changed in GCC 12.1" }
I think you used "format=flawed" again?
Okay for trunk with such comment updates. Thanks!
Segher
modes is called, the name GET_MODE_INNER is a bit confusing
though :-) )
Btw, the documentation for "concat" says
@findex concat
@item (concat@var{m} @var{rtx} @var{rtx})
This RTX represents the concatenation of two other RTXs. This is used
for complex values. It should only appear in the RTL attached to
declarations and during RTL generation. It should not appear in the
ordinary insn chain.
which needs some updating (in many ways).
Segher
> + void *buffer[10];
> +
> + addresses = backtrace(buffer, 10);
> + if(addresses != 4)
> +__builtin_abort();
> +}
Does that work?! Has this been tested on all powerpc*-linux configs?
Importantly also BE and 32-bit.
Okay for trunk with the testcase fix, if all testing works out. Thanks!
Segher
On Wed, Sep 29, 2021 at 11:14:55AM -0300, Raphael M Zinsly wrote:
> On 28/09/2021 16:50, Segher Boessenkool wrote:
> >>+/* { dg-do run { target { powerpc*-*-linux* } } } */
> >
> >Don't say such targets in gcc.target/powerpc/ tests please. Everything
> >in gcc
Unless you can convince me (in the patch / commit
message) that this is safe :-)
Whichever way you choose, it is likely best to do the same on 10 and 11
as on trunk, since it will all be replaced on trunk soon anyway.
Segher
* while
that isn't really necessary).
Why do you need/want the check_effective_target_dfp test? If for example
this is to prevent ICEs, that is no good, that is *hiding* problems.
I suspect it is to stop the testsuite from complaining if you configure
with --disable-decimal-float. What is different there then, compared to
targets that do actually not support decimal float?
Okay for trunk minus the changes to powerpc-dfp.exp (we can iterate on
that). Thanks!
Segher
On Wed, Dec 04, 2019 at 01:56:45PM -0600, Peter Bergner wrote:
> On 12/4/19 1:16 PM, Segher Boessenkool wrote:
> > Why do you need/want the check_effective_target_dfp test? If for example
> > this is to prevent ICEs, that is no good, that is *hiding* problems.
> >
> >
On Wed, Dec 04, 2019 at 08:47:49PM +, Iain Sandoe wrote:
> Peter Bergner wrote:
> >On 12/4/19 1:16 PM, Segher Boessenkool wrote:
> >>This isn't run from powerpc.exp, so it needs to still do that first check.
> >>And it's up to the Darwin maintaine
being run for
> you. Otherwise, you'll have to hunt through the DFP tests looking for
> a dg-skip-if darwin test.
Yes, and most of those skip-if do not document *why* it is disabled,
either!
Segher
On Wed, Dec 04, 2019 at 03:53:30PM -0600, Peter Bergner wrote:
> On 12/4/19 2:50 PM, Segher Boessenkool wrote:
> > It would be nice to keep *some* dfp test(s) to make sure we don't ICE.
> > If we disabled all such tests already, like with this patch, we wouldn't
> >
Hi Alan,
Thanks for looking, and for the corrections :-)
On Thu, Dec 05, 2019 at 09:26:09AM +1030, Alan Modra wrote:
> On Mon, Dec 02, 2019 at 06:07:23PM -0600, Segher Boessenkool wrote:
> > Is that "paddi" syntax correct? I think you might mean
> > "paddi
ot; forces you to uglify your code, then maybe
it is not such a nice feature, and you should not use it.
If you have issues with scoping your functions are WAY too long already.
Segher
ould not indent that far, so this all
works out splendidly.
Segher
for a piece of code, it is probably not chosen
as a good factor anyway!
> and using
> way too long function names. If you look at the earlier suggestion where
> the code is indented reasonably, using the temporary there makes the code more
> readable and shorter.
Yup.
Segher
r 40 or whatever) lines ago, in WAY too long functions.
All those problems do not exist in well-factored code. The point is not
to have short routines: the point is to not have too much (external)
complexity per routine. A routine should ideally only do one thing, and
its name should describe what it does.
Segher
On Thu, Dec 05, 2019 at 03:38:15PM -0500, Marek Polacek wrote:
> On Thu, Dec 05, 2019 at 02:06:50PM -0600, Segher Boessenkool wrote:
> > > When you're forced to uglify every variable with a leading __ you run
> > > out of characters pretty damn quickly.
> >
> &g
On Thu, Dec 05, 2019 at 08:56:35PM +, Jonathan Wakely wrote:
> On Thu, 5 Dec 2019 at 20:07, Segher Boessenkool
> wrote:
> > On Thu, Dec 05, 2019 at 05:03:43PM +, Jonathan Wakely wrote:
> > > C++17 introduces a nice feature, with rationale similar to declaring
> >
On Thu, Dec 05, 2019 at 10:37:33PM +, Jonathan Wakely wrote:
> On Thu, 5 Dec 2019 at 22:19, Segher Boessenkool wrote:
> > Or you could write
> >
> > auto __c = (__builtin_memcmp(&*__first1, &*__first2, __len) <=> 0);
> > if (__c)
> >
case anyway?
Does it not already happen? You need dump files enabled, of course.
Segher
On Wed, Dec 04, 2019 at 07:43:30PM +0900, Oleg Endo wrote:
> On Tue, 2019-12-03 at 12:05 -0600, Segher Boessenkool wrote:
> > > Hmm ... the R0 problem ... SH doesn't override class_likely_spilled
> > > explicitly, but it's got a R0_REGS class with only one said r
On Thu, Dec 05, 2019 at 10:14:13AM +1030, Alan Modra wrote:
> On Wed, Dec 04, 2019 at 05:16:05PM -0600, Segher Boessenkool wrote:
> > > pla 9,ext_symbol@pcrel # add (0),1 for optional operands
> >
> > pla does not have optional operands like that?
>
> It does, jus
On Thu, Dec 05, 2019 at 08:44:57AM +, Iain Sandoe wrote:
> .. or I can just force a false return from effective_target_dfp as we
> do for other cases where assembler support does not imply system
> support.
That's what I would do, yes.
Segher
c64-linux {-m32,-m64}. (This defaults to power4, so
this code actually is tested then). Committing to trunk.
Segher
2019-12-09 Segher Boessenkool
* config/rs6000/rs6000.md (unnamed mfcr define_insn): Name this
set_cc.
(unnamed define_insn_and_split): Delete.
On Mon, Dec 09, 2019 at 01:48:51PM +0100, Martin Liška wrote:
> - gcc_assert (INSN_UID (insn) < DF_INSN_SIZE ());
> + gcc_assert (INSN_UID (insn) < (int)DF_INSN_SIZE ());
Space after cast please.
Segher
On Wed, Dec 11, 2019 at 07:39:38AM -0600, Bill Schmidt wrote:
> I can't approve this, but for what it's worth it looks fine to me.
But I can :-) Thanks for looking Bill!
The patch is okay for trunk. Thanks Ke Wen!
Segher
> >2019-12-11 Kewen Lin
> >
> &g
e of course, and it's simple as can be.
This configure thing does not gate whether the backend code supports
DFP though? Or is that handled somewhere? I.e. can we ever end up
with TARGET_DFP set while enable_decimal_float is not set?
Segher
come.
> And the current implementation is IMHO unusable for lra since it did not
> introduce a CC register to track clobbering. So it's a dead end.
I disagree. There *is* nothing to clobber, during LRA. There are no live
values.
Segher
On Thu, Dec 12, 2019 at 09:32:27AM +, Richard Sandiford wrote:
> I doubt it will be long before we deprecate
> all targets that require old reload.)
Do we wait until GCC 12 (to remove old reload completely)? If not, we
should deprecate it now.
Segher
On Fri, Dec 13, 2019 at 10:06:20PM +0900, Oleg Endo wrote:
> On Fri, 2019-12-13 at 05:03 -0600, Segher Boessenkool wrote:
> > On Thu, Dec 12, 2019 at 09:32:27AM +, Richard Sandiford wrote:
> > > I doubt it will be long before we deprecate
> > > all targets that requi
On Fri, Dec 13, 2019 at 01:19:55PM +0100, Richard Biener wrote:
> On December 13, 2019 12:03:30 PM GMT+01:00, Segher Boessenkool
> wrote:
> >On Thu, Dec 12, 2019 at 09:32:27AM +, Richard Sandiford wrote:
> >> I doubt it will be long before we deprecate
> >>
On Sat, Dec 14, 2019 at 12:06:36AM +0900, Oleg Endo wrote:
> On Fri, 2019-12-13 at 15:57 +0100, John Paul Adrian Glaubitz wrote:
> > Hello Segher!
Hi :-)
> > > With LRA, sh builds fine (with the combine2 patches). I have no idea
> > > if correct code is generated,
one expression object of code @code{cc0}; it is the
value of the variable @code{cc0_rtx}. Any attempt to create an
expression of code @code{cc0} will return @code{cc0_rtx}.
There is a lot of code that depends on this property, you cannot break
it without fixing everything.
Segher
On Fri, Dec 13, 2019 at 08:55:15PM +0100, Stefan Franke wrote:
> Am 2019-12-13 18:58, schrieb Segher Boessenkool:
> >On Fri, Dec 13, 2019 at 05:25:41PM +0100, Stefan Franke wrote:
> >>Why? If you are using a cc register plus your architecture as many
> >>instruction
gnoring those is a great idea, unless you
are unlucky enough to have to use them ;-) ). So it isn't hard to handle
the "dataflow" for them, in principle, but it is special cases
*everywhere*.
Segher
It turns out we still used hardcoded register numbers for the CR fields
in some cases, and they now use the wrong numbers since we renumbered
most of the registers. So let's use the symbolic names, instead.
Committing to trunk.
Segher
2019-12-16 Segher Boessenkool
* config/r
t; 31 == -1 || value >> 31 == 0))
> return 1;
>
> + /* PADDI can support up to 34 bit signed integers. */
> + else if (TARGET_PREFIXED_ADDR && SIGNED_34BIT_OFFSET_P (value))
> +return 1;
Please follow up with a patch to not call random numbers "OFFSET".
Okay for trunk. Thanks!
Segher
it constants if -mcpu=future.
This is okay for trunk. Thanks!
Segher
ow eI constants.
> * config/rs6000/rs6000.md (add3): Add alternative to
> generate PADDI for 34-bit constants if -mcpu=future.
This is fine. Okay for trunk. Thanks!
Segher
d_memory" nor
"non_prefixed_memory"!
> --- gcc/doc/md.texi (revision 279182)
> +++ gcc/doc/md.texi (working copy)
> @@ -3373,6 +3373,12 @@ asm ("st %1,%0" : "=m<>" (mem) : "r" (va
>
> is not.
>
> +@item em
> +A memory operand that does not contain a prefixed address.
> +
> +@item ep
> +A memory operand that does contains a prefixed address.
Same comments as above.
Segher
t;))
> + (clobber (match_scratch:V2DI 4 "=&v,X,X,X,X"))
> + (clobber (match_scratch:DI 5 "=X,X,X,&b,&b"))]
>"VECTOR_MEM_VSX_P (mode) && TARGET_DIRECT_MOVE_64BIT"
>"#"
>"&& reload_completed"
>[(const_int 0)]
> {
>rs6000_split_vec_extract_var (operands[0], operands[1], operands[2],
> - operands[3], operands[4]);
> + operands[3], operands[4], operands[5]);
This writes to operands[2], which does not match its constraint.
Same in the other splitters.
Segher
On Tue, Dec 17, 2019 at 05:29:44PM -0500, Michael Meissner wrote:
> On Tue, Dec 17, 2019 at 11:15:29AM -0600, Segher Boessenkool wrote:
> > > +;; Return true if the operand is a valid memory address that does not
> > > use a
> > > +;; prefixed add
tors or similar?
Segher
Hi!
On Tue, Dec 17, 2019 at 07:38:51PM -0500, Michael Meissner wrote:
> On Tue, Dec 17, 2019 at 05:35:24PM -0600, Segher Boessenkool wrote:
> > And what is with the INSN_FORM_PCREL_EXTERNAL?
>
> INSN_FORM_PCREL_EXTERNAL says that the operand is a reference to an external
>
(Whoops, I missed replying t this one. Sorry.)
On Tue, Dec 10, 2019 at 12:27:11PM -0600, Peter Bergner wrote:
> On 12/4/19 5:03 PM, Segher Boessenkool wrote:
> > On Wed, Dec 04, 2019 at 03:53:30PM -0600, Peter Bergner wrote:
> >> Right. I'll come up with a patch and hopef
ot.
Same comments for the p8 test of course. Okay with or without those
adjusted (they aren't wrong, just weird style).
Thanks,
Segher
Hi!
On Wed, Dec 18, 2019 at 05:15:21PM -0500, Michael Meissner wrote:
> In the patch:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01201.html
>
> Segher Boessenkool asked me to submit a patch to rename the macros used to see
> if a number is a valid signed 16 or 34-bit value
1001 - 1100 of 6132 matches
Mail list logo
