he int : 0 in empty bases
> or in zero sized [[no_unique_address] fields would be quite hard to
> implement (because for C++14 the FIELD_DECL just isn't there).
I have no idea what "no_unique_address" is (what the name is, mostly?)
It seems to me that we would be *much* better off saying what we want it
to *do*, if we are going to depend on that effect anyway!
Segher
On Tue, Apr 28, 2020 at 06:45:05PM +0200, Jakub Jelinek wrote:
> On Tue, Apr 28, 2020 at 11:32:02AM -0500, Segher Boessenkool wrote:
> > > G++ 9 -std=c++14 A, B, C passed in fprs, the rest in gprs
> > > G++ 9 -std=c++17 A passed in fprs, the rest in gprs
>
;;
> - powerpc64)
> + powerpc64|powerpc64le)
> druntime_target_cpu_parsed="powerpc64"
> ;;
>i[34567]86|x86_64)
We are a biarch target, so both powerpc-* and powerpc64-* configurations
can do both those configs (potentially, and the default for many configs).
Segher
);
None of these are valid double-double numbers (they all underflow or
overflow).
> /**Big overflow or underflow*/
> testNumberConvert!("cast(double)-0x9.0f7ee55df77618fp-13829L");
> testNumberConvert!("cast(double)0x7.36e6e2640120d28p+8797L");
> testNumberConvert!("cast(double)-0x1.05df6ce4702ccf8p+15835L");
> testNumberConvert!("cast(double)0x9.54bb0d88806f714p-7088L");
> testNumberConvert!("cast(float)-0x9.0f7ee55df77618fp-13829L");
> testNumberConvert!("cast(float)0x7.36e6e2640120d28p+8797L");
(Exactly like these).
Segher
t support files were being compiled in.
>
> Segher, is this OK?
If it fixes the bootstrap breakage, that is good :-)
> * configure: Regenerated.
"Regenerate." (Not passive).
> diff --git a/libphobos/libdruntime/config/powerpc/switchcontext.S
> b/libphobos/li
Hi!
On Tue, Apr 28, 2020 at 12:25:04AM -0300, Alexandre Oliva wrote:
> On Apr 24, 2020, Segher Boessenkool wrote:
>
> >> > since all the top bits are zeros always, it will always be a subnormal
> >> > number, so all comparisons will work as expected / wanted
On Tue, Apr 28, 2020 at 07:15:58PM -0300, Alexandre Oliva wrote:
> On Apr 28, 2020, Segher Boessenkool wrote:
>
> > s/mmfl/mffs/
> > s/mmfs/mffs/
> > s/mmsl/mffsl/
>
> Oh, my, looks like I missed some mispellings of ffmls :-P
It helps to read the mnemonics
} */
> +/* { dg-require-effective-target powerpc_future_ok } */
> +/* { dg-options "-O2 -mdejagnu-cpu=future -mpcrel" } */
> +
> +int array[8];
> +int
> +foo (void)
> +{
> + return __builtin_bswap32 (array[1]);
> +}
That part is okay for trunk, of course :-)
Segher
(plus:P (symbol_ref:P S) (const_int D)))
What are the actual rules? Where is this documented?
Of course it is highly desirable to have CONST around such constant
addresses, but when is it *required*? And what *is* a constant address
(in this context)?
Segher
On Wed, Apr 29, 2020 at 08:56:11AM -0600, Jeff Law wrote:
> On Tue, 2020-04-28 at 20:03 -0500, Segher Boessenkool wrote:
> > What are the actual rules? Where is this documented?
> >
> > Of course it is highly desirable to have CONST around such constant
> > addresse
ly
> +proc check_effective_target_powerpc_prefixed_addr { } {
> +return [check_no_messages_and_pattern powerpc_prefixed_addr \
> + {\mpld\M} assembly {
> + long foo (long *p) { return p[0x12345]; }
> + } {-O2 -mcpu=future}]
> +}
Similar here.
Segher
stsuite should usually use "int" and "long long", for 32-bit resp.
64-bit items, so that it works on both 32-bit and 64-bit configureations;
and "long" for register size. Both "int" and "long" will work fine here.
The patch is okay for trunk, once the effective target situation has been
worked out.
Segher
*)(p + 1) = f; /* should generate STF. */
>
> Comment should be STFD ?
>
> > +}
> > +
> > +void
> > +store_double_offset1 (double d, unsigned char *p)
> > +{
> > + *(double *)(p + 1) = d; /* should generate STD. */
>
> Comment should be STFS ?
The other way around :-) stfs is for single precision float ("float",
in C), while stfd is for double precision float ("double", in C).
> > +/* { dg-final { scan-assembler-times {\mextsb\M} 1 } } */
Maybe also test there are no extsh and extsw generated?
Segher
file. (And both instructions are
generated only once).
Segher
ot; or "no-update-forms" ? I
> don't immediately see why "modify" is referenced.
The Power ISA calls it "update form", while GCC calls it "pre-modify"
("pre-increment", "pre-decrement"), or "address side effects", for how
it is put in RTL.
The ISA name makes more sense here I think, yes.
Segher
we do with non-prefixed code (or is there any significant difference?)
but maybe that should be looked at again as well. (Maybe it doesn't
happen often enough to matter either way?)
Segher
of files who previously relied on this transitive include.
>
> Note that we have a tool to help prune unused includes, somewhere.
contrib/header-tools/reduce-headers? And see gcc-order-headers.
Segher
> (define_expand "load_macho_picbase"
> - [(set (reg:SI LR_REGNO)
> + [(set (reg LR_REGNO)
This changes it to VOIDmode instead? It should have been reg:P LR_REGNO?
> (define_expand "reload_macho_picbase"
> - [(set (reg:SI LR_REGNO)
> + [(set (reg LR_REGNO)
Same here.
Segher
On Wed, Sep 25, 2019 at 04:52:14PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Thu, Sep 12, 2019 at 08:51:59AM +0100, Richard Sandiford wrote:
> >> Segher Boessenkool writes:
> >> > It is not such a great name like that. Since its children
t; +SECURE_PLT = $(if $(findstring TARGET_FREEBSD32_SECURE_PLT=1,
> $(tm_defines)),msecure-plt)
> +
> +MULTILIB_EXTRA_OPTS += $(SECURE_PLT)
$(findstring) isn't super great, it looks for substrings, so it would
also match "TARGET_FREEBSD32_SECURE_PLT=123"; you can use $(filter) instead?
Looks fine to me either way.
Segher
is okay for trunk. Thank you!
Segher
On Thu, Sep 26, 2019 at 12:06:03PM -0500, Bill Schmidt wrote:
> On 9/26/19 12:00 PM, Segher Boessenkool wrote:
> >On Thu, Sep 26, 2019 at 10:40:29AM -0500, will schmidt wrote:
> >>Update our (rs6000) vector load built-ins with the PURE attribute. These
> >>were previou
I 124)
> (expr_list:REG_DEAD (reg/v:SI 115 [ sec ])
> (nil))
This is not a correct pattern for umlal (it should have a carry from the
low half of the addition to the high half).
Segher
On Fri, Sep 27, 2019 at 12:30:50AM +0200, Jakub Jelinek wrote:
> On Thu, Sep 26, 2019 at 05:17:40PM -0500, Segher Boessenkool wrote:
> > On Wed, Sep 25, 2019 at 10:06:13PM -0600, Jeff Law wrote:
> > > (insn 14 13 16 2 (parallel [
> > > (set (reg:SI 132)
>
hat in testcases.
I'm skipping the rest of the testcases for now.
So, okay, it looks like it works :-) And I have confidence the testcases
will exercise most of the code. But I have two main concerns.
First, some of the code is quadratic. This is esp. bad for things that
iterate over insns in a basic block, since you easily can have 10k or
more insns in a bb. But it isn't good for iterating over bbs either, you
can have many of those as well. And df_link's, etc.
Second, the main core of this is a few huge routines, with many nested
loops and conditionals. This is hard to follow.
Can you fix those things? (And the comments above, most of which are nits,
but most of those apply many times).
Segher
th what you had, but please add a comment saying the template
won't ever be inserted as instruction.
(Maybe one of the gen* tools complains any_fix needs a mode? :QI will do
if so, or :P if you like that better).
With either way, approved for trunk (after testing, of course). Thanks!
Segher
On Fri, Sep 27, 2019 at 10:08:46AM +0200, Jakub Jelinek wrote:
> On Thu, Sep 26, 2019 at 05:34:25PM -0500, Segher Boessenkool wrote:
> > > Are you sure?
> > > "The UMLAL instruction interprets the values from Rn and Rm as unsigned
> > > integers. It multiplies
rning (from genrecog.c) only happens for a SET,
so you won't get it here. It would be a warning, not an error, btw.
Segher
e call the enum non_prefixed_form.
With those nits fixed, this is fine for trunk. Thank you!
Segher
ed_load_p and prefixed_store_p should test for
"indexed" "no" and "update" "no" themselves? The code here simplifies
a bit then.
(blank line before the default case please).
> + (const_string "no")))
Okay for trunk with those things fixed. Thanks!
Segher
okay for trunk. Thanks!
Segher
> 2019-09-18 Michael Meissner
>
> * config/rs6000/rs6000.md (mov_64bit_dm): Split the
> alternatives for loading 0.0 to a GPR and loading a 128-bit
> floating point type to a GPR.
has only one permute
unit?), and assuming geomean is fine too.
Thanks!
Segher
s a bit
better.
The rest should be worked out a bit more, but looks promising.
Did you test this with both "make info" and "make pdf" (and checked the
result of those of course :-) )?
Thanks,
Segher
alidate partially-clobbered
> > registers as well as fully-clobbered ones.
> OK if Segher doesn't object.
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01462.html
"That looks great, thanks!"
:-)
Segher
utput {(?n)warning: warning: .* possibly used unsafely; consider
using} } */
(?n) means to match single lines only; . and bracket expressions using ^
will not match newlines if you use it.
("warning: " twice, btw?)
Segher
On Mon, Sep 30, 2019 at 03:36:41PM +0200, Ilya Leoshkevich wrote:
> > Am 06.09.2019 um 12:34 schrieb Segher Boessenkool
> > :
> > Should you handle -fsignaling-nans here as well?
>
> Do you mean disabling vectorisation of LE/LT/GE/GT/LTGT when
> -fsignaling-nans is i
ns max.
> * config/rs6000/rs6000.md (movmemsi): Add new pattern.
> (cpymemsi): Add might_overlap parm to expand_block_move() call.
Okay for trunk. Thanks!
Segher
nches after an appropriate
> waiting period?
Yes please. Thanks,
Segher
> 2019-09-30 Bill Schmidt
>
> * config/rs6000/rs6000-p8swap.c (rtx_is_swappable_p): Don't swap
> vpmsumd.
>
> [gcc/testsuite]
>
> 2019-09-30 Bill Schmidt
>
> * gcc.target/powerpc/pr91275.c: New.
Hi!
On Mon, Sep 30, 2019 at 09:47:13AM +0800, luoxhu wrote:
> On 2019/9/30 00:17, Segher Boessenkool wrote:
> The updated output will be as below in gccint.pdf, references are valid to
> jump over
> (suppose should be the same in info?):
> > Did you test this with both "m
It says " size N/2" in a few places where "size S/2" is meant.
Committing as trivial and obvious.
Segher
2019-10-01 Segher Boessenkool
* doc/md.texi (vec_pack_trunc_@var{m}): Fix typo.
(vec_pack_sfix_trunc_@var{m}, vec_pack_ufix_t
trunk?
Segher
2019-10-01 Segher Boessenkool
* regrename.c (hide_operands): Use pc_rtx instead of cc0_rtx.
---
gcc/regrename.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/regrename.c b/gcc/regrename.c
index 8c3bae8..ed1dcde 100644
--- a/gcc/regrename.c
On Tue, Oct 01, 2019 at 10:18:37AM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> It's mentioned by name later too:
>
> /* Step 2: Mark chains for which we have reads outside operands
>as unrenamable.
>We do this by mungin
prefixed_length")
> + (cond [(and (eq_attr "alternative" "4") ;; MTVSRDD
> + (match_test "TARGET_P9_VECTOR"))
> + (const_string "4")
> +
> +(eq_attr "alternative" "3,4");; GPR <-> VSX
> +(const_string "8")
TARGET_P9_VECTOR is always true for alt 4 (it uses the "we" constraint).
And exactly the same is true for alt 3? And MTVSRDD has nothing to do
with it?
> +
> +(eq_attr "alternative" "5,6,7,8");; GPR load/store
> +(const_string "8")]
> + (const_string "*")))
This loses that alt 13 was len 20, what happened there? And alts 9 and 14?
> @@ -3235,9 +3255,10 @@ (define_insn "vsx_vslo_"
> ;; Variable V2DI/V2DF extract
> (define_insn_and_split "vsx_extract__var"
>[(set (match_operand: 0 "gpc_reg_operand" "=v,wa,r")
> - (unspec: [(match_operand:VSX_D 1 "input_operand" "v,m,m")
> - (match_operand:DI 2 "gpc_reg_operand" "r,r,r")]
> - UNSPEC_VSX_EXTRACT))
> + (unspec:
> + [(match_operand:VSX_D 1 "reg_or_non_pcrel_memory" "v,em,em")
> + (match_operand:DI 2 "gpc_reg_operand" "r,r,r")]
> + UNSPEC_VSX_EXTRACT))
Please explain why this needs to be non-pcrel (and split this to a separate
patch if possible).
Segher
cc-20191001/gcc/testsuite/gcc.dg/ipa/ipa-sra-19.c:17:12: warning:
> GCC vector returned by reference: non-standard ABI extension with no
> compatibility guarantee [-Wpsabi]
Yeah. Many tests add -Wno-psabi to shut these up; is that good here?
Segher
On Wed, Oct 02, 2019 at 03:04:35PM -0400, Michael Meissner wrote:
> On Tue, Oct 01, 2019 at 06:56:01PM -0500, Segher Boessenkool wrote:
> > On Mon, Sep 30, 2019 at 10:12:54AM -0400, Michael Meissner wrote:
> > > I needed
> > > to add a second memory constraint ('eM&
0, 0x0040 }, /* SFP_REG */ \
{ 0x, 0x, 0x, 0x0080 }, /* AFP_REG */ \
{ 0x7FFF, 0x, 0x, 0x000F } /* ALL_REGS */\
and that last number should be 0x00ff instead?
Segher
On Thu, Oct 03, 2019 at 10:35:15AM +0100, Richard Earnshaw (lists) wrote:
> On 03/10/2019 00:01, Segher Boessenkool wrote:
> >The documentation says
> >
> >@findex ALL_REGS
> >@findex NO_REGS
> >In general, each register will belong to several classes. In fact,
ecause this hides the fetch latency when a branch is
predicted correctly.
When a (conditional) branch executes, it is detected if the branch was
mispredicted, and if so it (and everything after it) is flushed. This is
similar to how it was done on the PowerPC 6xx CPUs, or on the original
Pentium, etc.
Segher
rs of a
> single class? In practice it doesn't matter because nothing ever
> uses these classes [ ... ]
Yeah exactly. Register classes only matter for allocatable registers.
Thanks for the exposition,
Segher
On Thu, Oct 03, 2019 at 12:16:46PM +0100, Maciej W. Rozycki wrote:
> On Thu, 3 Oct 2019, Segher Boessenkool wrote:
> > When a (conditional) branch executes, it is detected if the branch was
> > mispredicted, and if so it (and everything after it) is flushed. This is
> > simil
On Thu, Oct 03, 2019 at 09:26:45AM -0400, Paul Koning wrote:
> > On Oct 3, 2019, at 9:12 AM, Richard Earnshaw (lists)
> > wrote:
> >
> > On 03/10/2019 10:48, Segher Boessenkool wrote:
> >>> ...
> >> But ALL_REGS should contain *all* registers. The
ace now. As you see
we *do* have a little bit nicer things than this, already. But it is so
fundamental that changing anything means changing quite some passes, and
changing all backends, and none of this is trivial.
Segher
line frames.
> gdbinit.in has a lengthy list of inlines to skip in rtl.h, shouldn't this be
> added to that list? Not 100% sure how well it will work on rtl checking
> vs. non-rtl checking builds.
Also, how much slower does it make RTL checking builds?
Segher
m, long another)
{
lots of code;
}
The point is that all this is completely *local* changes.
Segher
t is completely harmless. If you write in non-ancient style
(so write shortish functions and blocks, and declare every var at its
first use) you don't see actual shadowing problems much at all.
In most cases here the warning indicates that the code it too big (and
too old), it could use a bit of factoring and rewriting.
But all this patch does is shut up the warnings, without fixing the causes.
This is not an improvement. Hiding problems is bad.
Segher
On Sat, Oct 05, 2019 at 08:28:26AM +, Bernd Edlinger wrote:
> On 10/5/19 9:26 AM, Segher Boessenkool wrote:
> > On Fri, Oct 04, 2019 at 02:26:26PM -0600, Jeff Law wrote:
> > To get 95% of the benefit for only 2% of the pain, you can make an inline
> > function where the
>
> Set MD_STARTFILE_PREFIX to $prefix/lib/ and MD_STARTFILE_PREFIX_1 to
> $at/lib/ so that a compiler library has preference over the Advance
> Toolchain libraries.
This is fine, approved for all branches. Thank you! And thanks to Mike
for the testing.
Segher
> 2019-10-04 Tulio Ma
Hi Bernd,
On Sat, Oct 05, 2019 at 09:12:19AM +, Bernd Edlinger wrote:
> On 10/5/19 10:08 AM, Segher Boessenkool wrote:
> > I'll just review the combine part.
> >
> > On Sat, Oct 05, 2019 at 06:36:34AM +, Bernd Edlinger wrote:
> >> --- gcc/combin
ros. Not the most exciting work, but useful.
Segher
g
> variable is declared...
The best thing would be to write this in a way that nothing *can*
accidentally shadow something.
Segher
d
> LINK_OS_EXTRA_SPEC64 to MD_STARTFILE_PREFIX and
> MD_STARTFILE_PREFIX_1 when using --with-advance-toolchain.
Committed ( https://gcc.gnu.org/r276702 ). Thanks!
Segher
go, and it is quite hard :-/ It's not
forgotten though!
Segher
nnot know if another frame has been
stacked by the current function already, or not).
Segher
r8 and Power9 is +0.06%, and it's unchanged for SPEC2006
> Power8.
Small steps :-)
The patch is okay for trunk. Thank you!
Segher
> * config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Lower
> vec_promote_demote cost to 1 for non-Power7 VSX architectures.
return 1;
> +
> + /* Handle prefixed addresses (PC-relative or 34-bit offset). */
> + if (address_is_prefixed (x, mode, NON_PREFIXED_DEFAULT))
> +return 1;
Is this correct? Are addresses with a larger offset always legitimate?
I don't see why that would be the case.
The rest of the patch looks good, thanks.
Segher
On Wed, Oct 09, 2019 at 07:40:23PM -0400, Michael Meissner wrote:
> On Wed, Oct 09, 2019 at 04:56:48PM -0500, Segher Boessenkool wrote:
> > On Fri, Oct 04, 2019 at 08:29:11AM -0400, Michael Meissner wrote:
> > > @@ -8651,6 +8675,11 @@ rs6000_legitimate_addr
k for a 34-bit offset instead of 16-bit.
s/ If/ If/
Okay for trunk. Thanks!
Segher
; reload_completed"
>[(pc)]
> -{ rs6000_split_multireg_move (operands[0], operands[1]); DONE; }
> - [(set_attr "length" "8,8,8,12,12,8")])
> +{
> + rs6000_split_multireg_move (operands[0], operands[1]);
> + DONE;
> +}
> + [(set_attr "non_prefixed_length" "8")
> + (set_attr "prefixed_length" "20")])
It used to be 8,8,8,12,12,8 before. Was that in error? Please explain.
Segher
be extended to also handle a SIGN_EXTEND the same way.
That works, sure. Approved for trunk. Thanks!
Segher
prefixed instruction (16) or two back
> + to back prefixed instructions (20). */
> + else if (length == 16 || length == 20)
> + n = 2;
> +
> + /* Guess for larger instruction sizes. */
> + else
> + n = 2 + (length - 20) / 4;
That's a pretty bad estimate.
Can you look at non_prefixed_size, will that help?
Segher
er a register operand or a memory operand that does
> +;; not use a prefixed address.
> +(define_predicate "reg_or_non_prefixed_memory"
> + (match_code "reg,subreg,mem")
> +{
> + return (gpc_reg_operand (op, mode) || non_prefixed_memory (op, mode));
> +})
This never allows subreg.
Segher
d to make the define_insns just *work* with
prefixed insns, instead? Is there any reason we are sure these memory
references will not turn into something that needs prefixed insns, after
expand? It seems fragile like this.
> +@item em
> +A memory operand that does not contain a prefixed address.
"A memory operand that does not require a prefixed instruction"?
Segher
"*, *, *, 8, *, 20,
> +20,20,20,8, *, *,
> +*, 20,8, *, *")
Alternative 13 has non_prefixed_length 20, I wonder what insns that
generates?
Other than that, looks good afaics.
Segher
unction
without VSX enabled should not be inlined into one with VSX enabled,
because it may be important it is disabled there; see PR70010. */
It's not clear to me why this is important, and what makes -mvsx different
from all other similar options?
Segher
that for colors;
Do we? I've had GCC_COLORS= since forever; is this finally not needed
anymore? Neat :-) Now just ASAN_OPTIONS=color=never TSAN_OPTIONS=color=never
by default and there is a bit of sanity again.
> Is this working/broken for other people?
I've only tried your example so far, and that does not work :-(
Segher
the symbol refers,
> + we assume optimistically it is "enough".
> + ??? maybe we should be pessimistic instead. */
> + unsigned align = 0;
If you guess it is aligned enough but it isn't, the compile will fail. Not
good. OTOH, when don't we know the alignment? Only for globals? Does the
ABI guarantee alignment in that case?
I'll have another looke through this (esp. the generic part) when I'm fresh
awake (but not before coffee!). Alan, can you have a look as well please?
Segher
cit means explicit, for everything I
tried anyway).
Segher
policy is that you should use noinline on the
callee in such cases?
Segher
On Mon, Oct 14, 2019 at 05:12:56PM -0400, Michael Meissner wrote:
> On Thu, Oct 10, 2019 at 05:02:09PM -0500, Segher Boessenkool wrote:
> > > @@ -7786,8 +7790,12 @@ (define_insn_and_split "*movtd_64bit_nod
> > >"#"
> >
On Mon, Oct 14, 2019 at 05:16:03PM -0400, Michael Meissner wrote:
> On Fri, Oct 11, 2019 at 04:17:02PM -0500, Segher Boessenkool wrote:
> > > * config/rs6000/predicates.md (lwa_operand): Allow using PLWA to
> > > generate sign extend with odd offsets.
> >
>
Hi!
On Mon, Oct 14, 2019 at 07:18:11PM -0500, Peter Bergner wrote:
> On 10/14/19 2:57 PM, Segher Boessenkool wrote:
> > On Mon, Oct 14, 2019 at 06:35:06PM +0200, Richard Biener wrote:
> >> The general case should be that if the caller ISA supports the callee one
> >> t
yway?
> +
> + if (((caller_isa & callee_isa) == callee_isa)
> + && (caller_isa & explicit_isa) == (callee_isa & explicit_isa))
> + ret = true;
> +}
Segher
On Tue, Oct 15, 2019 at 11:52:26AM +0200, Andreas Schwab wrote:
> On Okt 15 2019, Segher Boessenkool wrote:
>
> > Please use
> > /* { dg-final { scan-assembler "\mbl vadd_no_vsx\M" } } */
>
> ITYM
>
> /* { dg-final { scan-assembler {\mbl vadd_no_v
mless, while inlining can be
fatal. I don't see how we can handle both scenarios optimally.
> Just
> think of LTO, C++ and comdats - you'll get a random comdat entity
> at link time for inlining - either from the VSX CU or the non-VSX one.
This would make LTO totally unusable, with or without this patch? Something
else must be going on?
Segher
On Tue, Oct 15, 2019 at 01:19:51PM +0200, Richard Biener wrote:
> On Tue, Oct 15, 2019 at 12:07 PM Segher Boessenkool
> wrote:
> > On Tue, Oct 15, 2019 at 11:32:27AM +0200, Richard Biener wrote:
> > > > I think we just need to fix the bug in the current logic when chec
On Tue, Oct 15, 2019 at 12:47:02PM -0500, Peter Bergner wrote:
> On 10/15/19 4:56 AM, Segher Boessenkool wrote:
> > On Tue, Oct 15, 2019 at 05:15:07PM +0800, Jiufu Guo wrote:
> >> And another issue: Behavior is still inconsistent between "-mno-vsx
> >> -flto" a
As PR92107 shows, genattrtab doesn't parenthesize expressions correctly
(or at all, even). This fixes it.
I'll commit it as trivial and obvious if my bootstrap with it shows no
problems (or someone tells me not to, of course).
Segher
2019-10-15 Segher Boessenkool
istinctly remember is the promotion of integer
> loop induction variables to ptrdiff_t then using them in pointer
> arithmetic generated *horrible* code.
Heh.
Segher
-0,0 +1,20 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_vsx_ok } */
This line isn't necessary anymore I think? Or if it is, it is needed in
all these new testcases.
> +/* { dg-options "-O2 -finline-functions" } */
> +/* { dg-final { scan-assembler {\mbl vadd_no_vsx\M} } } */
Okay for trunk. Thanks to both of you!
Also okay for 9 and 8, after waiting a week to see if there is fallout.
Segher
(const_int 536870912 [0x2000]))
(and:SI (subreg:SI (reg/v:DI 125 [ yD.2902+-4 ]) 4)
(const_int -536870913 [0xdfff]
If the mask is not a constant, we really shouldn't generate a totally
different form. The xor-and-xor form is very hard to handle, too.
Expand currently generates this, because gimple thinks this is simpler.
I think this should be fixed.
Segher
W), since forever we have had this GCC extension, and
people expect it. (Or so I fear, feel free to prove me wrong :-) )
Segher
On Wed, Oct 16, 2019 at 09:04:18PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > This isn't canonical RTL. Does combine not simplify this?
> >
> > Or, rather, it should not be what we canonicalise to: nothing is defined
> > here.
>
> Bu
s at a time. We could do this by loading from memory,
> ;; and this is even supposed to be faster, but it is simpler not to get
> ;; integers in the TOC.
> -(define_insn "movsi_low"
Should the preceding comment be moved elsewhere / changed / deleted?
Segher
On Thu, Oct 17, 2019 at 01:46:41PM +1030, Alan Modra wrote:
> On Sat, Oct 12, 2019 at 05:39:51PM -0500, Segher Boessenkool wrote:
> > On Sat, Oct 12, 2019 at 10:13:16PM +0100, Iain Sandoe wrote:
> > > For 32bit cases this isn't a problem since we can load/store to unaligned
On Thu, Oct 17, 2019 at 10:37:33AM +0100, Iain Sandoe wrote:
> Segher Boessenkool wrote:
>
> > Okay for trunk. For backports maybe wait a bit longer than usual? So ask
> > again in two weeks, maybe? I know it's important for the darwin port, but
> > the generic pa
On Wed, Oct 16, 2019 at 11:44:37PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> >> If someone wants to add a new canonical form then the ports should of
> >> course adapt, but until then I think the patch is doing the right thing.
> >
> > We u
On Fri, Mar 15, 2019 at 05:14:48PM -0500, Segher Boessenkool wrote:
> On Fri, Mar 15, 2019 at 04:25:01PM -0400, Vladimir Makarov wrote:
> > On 2019-03-15 2:30 p.m., Segher Boessenkool wrote:
> > >PR89721 shows LRA treating an unspec_volatile's result as invariant,
>
e original_base_use and original_index_use
> + fields represent the numbers of the instructions that define the
> + base and index values which are summed together with a constant
> + value to determine the value of this instruction's memory
> + address. */
> + unsigned int original_base_use;
> + unsigned int original_index_use;
I wonder how you determine what is base and what is index?
(I'll review the rest later).
Segher
sert (!reload_completed || !crtl->has_bb_partition);
Thanks for the assert, that will help prevent people from running into
this again.
The patch looks fine to me, but I'm not a global reviewer :-)
Segher
ad
> to poor choices by combine. Recognising all the possible variants is
> a little trickier than normal because the expressions can become complex
> enough that this is no single canonical from.
There also is the insn_cost hook, which especially for RISC-like targets
is a lot easier to define.
Segher
2101 - 2200 of 6092 matches
Mail list logo
