n. I'll do that ans retest. Thanks for catching this.
Peter
On Wed, 2015-04-22 at 17:16 -0500, Segher Boessenkool wrote:
> On Wed, Apr 22, 2015 at 08:43:10AM -0500, Peter Bergner wrote:
> > > Maybe you can fold tabortdc with tabortwc now? Use one UNSPEC name
> > > for both, :GPR and ?
> >
> > Wouldn't that change the
wci, tbegin, tcheck, tend, trechkpt, treclaim, tsr): Use xor
instead of minus.
* config/rs6000/vector.md (cr6_test_for_zero_reverse,
cr6_test_for_lt_reverse): Ditto.
If so, I can back port it and test it along with mine. Otherwise, I'll
just work around it. Let me know what you want me to do.
Peter
gt; * gcc.target/powerpc/htm-builtin-1.c: Fix tcheck expect value.
>
>
> Okay.
This is broken on 4.9 and 4.8, so can we get those fixed as well?
Peter
On Mon, 2015-02-23 at 13:42 -0500, David Edelsohn wrote:
> On Mon, Feb 23, 2015 at 1:26 PM, Peter Bergner wrote:
> > This is broken on 4.9 and 4.8, so can we get those fixed as well?
>
> Yes, please backport.
I committed this to trunk on Adhemerval's behalf as revision 22099
est case that actually executes when
we're on power8.
Peter
Index: gcc.target/powerpc/htm-builtin-1.c
===
--- gcc.target/powerpc/htm-builtin-1.c (revision 220992)
+++ gcc.target/powerpc/htm-builtin-1.c (working copy)
@@ -
'll add it to the backports as well when I commit those after their
bootstrap/regtests are finished.
Peter
On Wed, 2015-02-25 at 16:22 -0600, Peter Bergner wrote:
> On Mon, 2015-02-23 at 13:42 -0500, David Edelsohn wrote:
> > On Mon, Feb 23, 2015 at 1:26 PM, Peter Bergner wrote:
> > > This is broken on 4.9 and 4.8, so can we get those fixed as well?
> >
> > Yes, please b
should look even better the next time we merge in the upstream ASAN code.
Ok for trunk? ...and is this ok now or should it wait for stage1?
Peter
* configure.tgt: Enable build on powerpc*le-*-linux.
Index: libsanitizer/configure.tgt
has fewer asan
failures than ppc64be and all of the ppc64le failures are also failures
in ppc64be, so ppc64le is actually in better shape than ppc64be.
Peter
On Thu, 2015-02-26 at 20:04 -0600, Peter Bergner wrote:
> On Thu, 2015-02-26 at 22:56 +0100, Jakub Jelinek wrote:
> > How do make check results (asan.exp/ubsan.exp) look like on ppc64le?
> > If it works as good as or better as ppc64be, then I'm fine with adding it
> >
On Fri, 2015-02-27 at 15:30 +0100, Markus Trippelsdorf wrote:
> On 2015.02.27 at 07:47 -0600, Peter Bergner wrote:
> >
> > Ok, since the results met your criteria for inclusion, I committed the
> > change as revision 221060. Thanks.
>
> Are there any plans to fix:
>
builtin return values. Is that ok?
Peter
gcc/:
PR target/64579
* config/rs6000/htm.md (tabort, tabortdc, tabortdci,
tabortwc, tabortwci, ttest, tcheck, tend, trechkpt,
treclaim, tsr): Use rs6000_emit_move_from_cr_field.
(tbegin, ta
ould Just Work as far
> as I see.
Heh, just cut/pasted the dg-do-skip from another test case, but yes,
we can remove it. Thanks.
It's too bad we can't have a "dg-do run" and a "dg-do compile", one
used when we're on HTM hardware and the other when we're not, so we
can at least compile the test case.
Peter
ven you've got a new ABI in play here, seems like the perfect time to
> bump the default ISA to something reasonable.
Agreed. Given the new ABI requires POWER8 as the minimum, I think this
patch is a no brainer.
Peter
tcheck insn does not have a '.' in its mnemonic,
so maybe this patch falls under the obvious rule?
It also goes to show that no one has actually used __builtin_tcheck()
before in a real progran, since the assembler would have flagged this
as an unknown opcode.
Thanks for fixing my mistake!
Peter
es I could
find that should have been using them, to use them. So the patch is large,
but pretty straight forward.
The passed bootstrap and regtesting on powerpc64le-linux with no regressions.
Ok for mainline?
Peter
* config/rs6000/altivec.md (build_vector_mask_for_load): Use MEM_P.
On 11/28/18 3:27 PM, Peter Bergner wrote:
> gcc/
> PR target/87496
> * config/rs6000/rs6000.c (rs6000_option_override_internal): Disallow
> -mabi=ieeelongdouble without both -mpopcntd and -mvsx.
So this "fix" ended up accidentally disallowing -mabi=ibmlon
lean?
>
> Okay with that documentation added and if it tests okay, yes. Thanks!
...and committed to trunk.
>> Since I backported the earlier fix to GCC8, I'd like to backport this
>> there too.
>
> Okay for there too.
Great, I'll backport the changes and commit after regression testing.
Thanks!
Peter
strap and regtesting with no errors and someone within
IBM how had a POWER9 box with a newish kernel how ran into the problem
confirmed it works for his test case.
Ok for mainline? Should be backport this?
Peter
* config/powerpc/target.h (PPC_FEATURE2_HTM_NO_SUSPEND): Conditionally
Ping.
Peter
On 12/4/18 10:12 AM, Peter Bergner wrote:
> Hi Segher,
>
> We talked about replacing rs6000'c regno_or_subregno() with the generic
> reg_or_subregno() function from jump.c. I agree the geberic version is
> better because it has an assert that ensures we hav
On 12/7/18 11:38 AM, Peter Bergner wrote:
> On 12/4/18 4:53 PM, Segher Boessenkool wrote:
>>> Since I backported the earlier fix to GCC8, I'd like to backport this
>>> there too.
>>
>> Okay for there too.
>
> Great, I'll backport the chan
or users not aware you defined
> it to 0. Since there are no other users yet it's no big deal.
Would you instead prefer something along the lines of the following?
Peter
static inline bool
htm_available (void)
{
- return (getauxval (AT_HWCAP2) & PPC_FEATURE2_HAS_HTM) ? true : fal
with either style. Thanks!
Ok, I'll go with this and commit once I've done another round of
testing. I'm assuming your backport approval still stands for this
code too.
Peter
On 11/16/18 5:29 PM, Segher Boessenkool wrote:
> On Fri, Nov 16, 2018 at 04:26:18PM -0600, Peter Bergner wrote:
>> However, when I made the change below, the length attribute seems a
>> little off. For *_64bit, we have a length of 4, but for *_32bit, we
>> have a length
On 12/13/18 10:42 AM, Peter Bergner wrote:
> On 12/13/18 2:41 AM, Segher Boessenkool wrote:
>> Or like
>>
>> unsigned long htm_flags = PPC_FEATURE2_HAS_HTM
>> #ifdef PPC_FEATURE2_HTM_NO_SUSPEND
>> | PPC_FEATURE2_HTM_NO_SUSPEND
>>
On 12/14/18 8:23 PM, Segher Boessenkool wrote:
> On Thu, Dec 13, 2018 at 10:59:36AM -0600, Peter Bergner wrote:
>> For the alternatives
>> I'm changing, we're loading into GPR regs and these alternatives are always
>> split (split2), so these length values are ne
On 12/17/18 3:55 PM, Segher Boessenkool wrote:
> On Mon, Dec 17, 2018 at 02:23:54PM -0600, Peter Bergner wrote:
>> This means we require the insn to eventually be split and not reach final
>> assembly, does it not?
>
> Yes, but is the length attribute used for something that
out adding a copy coalesce phase just before we enter RA,
which would ensure the copies are removed, instead of hoping RA assigns
the same reg to the source and destination of the copy making it a nop
that can be removed.
Peter
On 12/20/18 4:41 PM, Jeff Law wrote:
> On 12/20/18 2:30 PM, Peter Bergner wrote:
>> For stage1, I'd like to fix that conflict wart if I can. I have also
>> wondered about adding a copy coalesce phase just before we enter RA,
>> which would ensure the copies are rem
On 12/21/18 9:24 AM, Vladimir Makarov wrote:
> Peter, also if you are interesting to do RA work, there is another problem
> which is to implement sub-register level conflict calculations in LRA.
> Currently, IRA has a simple subregister level conflict calculation (see
> allocno objec
On 12/12/18 1:58 PM, Peter Bergner wrote:
> Ping.
Ping * 2.
https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00212.html
Peter
On 7/25/19 2:50 AM, Iain Sandoe wrote:
> This will break Darwin which has used DRIVER_SELF_SPECS in config/darwin.h
> since they were introduced (and the equivalent before).
>
> This is because Darwin has driver self-specs common to the PPC and X86 ports.
>
> If this change is seen the way to go,
Uros and Jan,
I should have CC'd you for the i386 portion of the patch. Are you ok with
the i386.h change if Iain's x86 Darwin testing comes out clean?
Peter
On 7/25/19 9:41 AM, Peter Bergner wrote:
> On 7/25/19 2:50 AM, Iain Sandoe wrote:
>> This will break Da
On 7/30/19 7:52 AM, Uros Bizjak wrote:
> On Thu, Jul 25, 2019 at 7:34 PM Peter Bergner wrote:
>>> +#define DRIVER_SELF_SPECS SUBTARGET_DRIVER_SELF_SPECS
>>> +
>>> +#ifndef SUBTARGET_DRIVER_SELF_SPECS
>>> +# define SUBTARGET_DRIVER_SELF_SPECS
>>>
n
its own set of '"'s. So "foo", "bar", "baz" etc. is fine, as is "foo bar baz",
but
"foo, bar, baz" is not ok. I guess it must have something to do with how we
scan the spec string. Anyway, since the darwin SUBTARGET_DRIVER_SEL
On 10/10/18 7:57 PM, Peter Bergner wrote:
> The problem is, that hard reg %r26 is defined in insn 32, to be used in
> insn 33, so using %r26 as the reload reg is wrong, because it will clobber
> the value we set in insn 32. Looking thru LRA, it looks like LRA assumes
> that for a re
On 10/11/18 1:18 PM, Peter Bergner wrote:
> Ok, after working in gdb, I see that the PA-RISC port still uses reload
> and not LRA, but it too seems to have the same issue of reusing input
> regs that have REG_DEAD notes, so the question still stands. It's just
> that whatever fi
On 10/11/18 2:40 PM, Jeff Law wrote:
> On 10/11/18 1:23 PM, Peter Bergner wrote:
>> On 10/11/18 1:18 PM, Peter Bergner wrote:
>>> Ok, after working in gdb, I see that the PA-RISC port still uses reload
>>> and not LRA, but it too seems to have the same issue of reusi
I built a newer binutils on our s390x box and I have now recreated the
selftest ICE in stage3 and I still have the largish aarch64 failure I'm
looking into.
Peter
On 10/11/18 10:40 PM, Jeff Law wrote:
> On 10/11/18 1:23 PM, Peter Bergner wrote:
>> * ira-lives (non_conflicting_reg_copy_p): Disable for non LRA targets.
> So this helped the alpha & hppa and sh4.
>
> I'm still seeing failures on the aarch64, s390x. No surpris
[] ice4.i:5)) "ice4.i":5 -1
(nil))
during RTL pass: reload
ice4.i:7:1: internal compiler error: in process_alt_operands, at
lra-constraints.c:2911
...
Thoughts? I'll note that this does not fix the S390 bugs, since those seem
to be due to problems with early clob
On 10/19/18 4:16 PM, Peter Bergner wrote:
> Thoughts? I'll note that this does not fix the S390 bugs, since those seem
> to be due to problems with early clobber operands and "matching" constraint
> operands. I'm still working on that and hope to have somethi
On 10/22/18 3:58 PM, Jeff Law wrote:
> On 10/19/18 4:39 PM, Peter Bergner wrote:
>> Jeff, maybe once Segher commits his patch, can you give this patch a try
>> on your testers?
> Once committed to the trunk it's automatically picked up :-) In fact,
> commits to the tru
On 10/22/18 6:40 PM, Peter Bergner wrote:
> On 10/22/18 3:58 PM, Jeff Law wrote:
>> On 10/19/18 4:39 PM, Peter Bergner wrote:
>>> Jeff, maybe once Segher commits his patch, can you give this patch a try
>>> on your testers?
>> Once committed to the trunk it'
On 10/22/18 7:20 PM, Segher Boessenkool wrote:
> Hi peter,
>> + /* If we have a matching constraint and both operands are hard
>> registers,
>> + then they must be the same hard register. */
>> + if (HARD_REGISTER_P (output)
>> + && H
On 10/22/18 6:45 PM, Peter Bergner wrote:
> Bah, my bootstrap failed and I need to make a small change. Let me do that
> and verify my bootstraps get all the way thru before I give you the updated
> patch. Sorry.
Ok, the following updated patch survives bootstrap and regtesting on
po
ne asm and the casp insn
is a bug in LRA where is will spill a user defined hard register and
it shouldn't do that. My patch above stops that. The question is
whether we've quashed the rest of the latent bugs.
Peter
On 11/3/18 1:01 AM, Stafford Horne wrote:
> Nevermind, I don not have write access. I will request to:
>
> overse...@gcc.gnu.org
>
Use the following form to request write access:
https://sourceware.org/cgi-bin/pdw/ps_form.cgi
Peter
On 11/5/18 1:20 PM, Jeff Law wrote:
> On 11/1/18 4:07 PM, Peter Bergner wrote:
>> On 11/1/18 1:50 PM, Renlin Li wrote:
>>> Is there any update on this issues?
>>> arm-none-linux-gnueabihf native toolchain has been mis-compiled for a while.
>>
>> From th
or -fno-ira-copies-conflict) is the same behavior
as now and -fira-copies-conflict would make things behave like they did
before my patch.
Peter
Index: gcc/common.opt
===
--- gcc/common.opt (revision 265402)
+++ gcc/common.opt
break;
...correct? I can add that. I don't think we need to modify
the other patch hunks, since we know operand_reg[x] is already
a reg.
Peter
> Segher may have been referring to this specific code. This is obviously
> safe to do as well.
>
> OK with this change.
He was. Thanks, I'll do one more bootstrap and then commit. Thanks!
Peter
On 11/7/18 11:36 AM, Jeff Law wrote:
> OK with this change.
Before I commit, how about I add the following test cases to test
both valid and invalid asm constraints? I think I have the reg
numbers for the other architectures defined correctly.
Peter
gcc/testsuite/
PR rtl-optimizat
int. Does it make sense?
Do you have a reproducer test case I can look at? I'd like to see the
problematical rtl to help me determine whether your patch is correct
or not. ...and thank you for debugging this!
Peter
it never
ends up in the "live" (ie, live and available) set, which can cause us to miss
some required conflicts.
That said, I still need to look at the RTL from the bad program before
determining whether the patch is correct or not. Computing accurate
conflict information is a delicate thing.
Peter
7;d miss adding the conflict between r1 and r2040.
Let me think about how we should solve this one.
And a *BIG* thank you for tracking down the problem!!!
Peter
the register which starts to go wrong. It is assigned as
> r1.
Yes, IRA and LRA have similar code to compute conflicts. We need them both to
compute that r2040 (and the reload pseudo(s) generated for it by LRA) conflict
with r1.
Peter
On 11/8/18 8:29 AM, Peter Bergner wrote:
> On 11/8/18 5:48 AM, Richard Biener wrote:
>> Esp. adding conflicts in a loop that says "See which defined values die
>> here."
>> is quite fishy.
>
> ..the original loop is dealing with some of the gory details
On 11/8/18 4:07 PM, Jeff Law wrote:
> On 11/7/18 7:17 PM, Peter Bergner wrote:
>> On 11/7/18 11:36 AM, Jeff Law wrote:
>>> OK with this change.
>>
>> Before I commit, how about I add the following test cases to test
>> both valid and invalid asm constraints? I
nize these word sized
rotates as simple moves so that it can replace the rotates with swapped
decomposed registers.
This has passed bootstrap and regtesting on powerpc64le-linux with no
regressions. Is this ok for mainline?
Peter
gcc/
PR rtl-optimization/87507
* lower-subreg.c (simpl
e tests
to make sure I have everything working correctly.
I'll also note I took the opportunity to convert lra-lives.c over to using
the HARD_REGISTER_P and HARD_REGISTER_NUM_P convenience macros.
Peter
gcc/
PR rtl-optimization/87899
* lra-lives
emps
and send me the resulting preprocessed source file? Also, can you give
me the gcc configure options you used to build your GCC? That should
give me enough info to debug this one. Thanks.
Peter
> This might annoy people for a while fixing user asm that we didn't
> diagnose previously, but I believe this is the right direction to go.
> Of course, -Wa,-many is available for anyone who just wants their
> dodgy old code to work.
+1
Peter
in and Jeff, can you apply this patch on top of the previous one
and see whether that is better?
Thanks.
Peter
--- gcc/lra-lives.c.orig2018-11-12 14:15:18.257657911 -0600
+++ gcc/lra-lives.c 2018-11-12 14:08:55.978795092 -0600
@@ -934,6 +934,18 @@
|| sparseset_contains_pseudo
with the above results, I think the patch is ready for review.
I'm attaching the latest updated patch below.
Again, this passed bootstrap and regtesting on powerpc64le-linux with
no regressions. Ok for mainline?
Peter
gcc/
PR rtl-optimization/87899
* lra-lives.c (sta
lation into a function here, for
> example
> resolve_operand_for_simple_move_operator?
Good idea. I went with your name, but would swap_concatn_operands() be a
better name, since that is what it is doing? I'll leave it up to you.
Updated patch below.
Peter
gcc/
P
I didn't change the vsx_mov_32bit pattern, since TImode
isn't supported with -m32. However, if you want, I could remove the
redundant "*r" <- "jwM" alternative there too?
This passes bootstrap and regtesting with no regressions. Ok for trunk?
Peter
gcc/
PR
ue to pass -many just for darwin
if they really really think they need it.
Peter
quot;
.machine pop
...
Hopefully the cctools supports that.
Peter
On 11/13/18 12:49 PM, Richard Henderson wrote:
> On 11/13/18 5:38 PM, Peter Bergner wrote:
>> On 11/13/18 2:53 AM, Eric Botcazou wrote:
>>> Superfluous semi-colon. Given that the function returns an operand, its
>>> name
>>> is IMO misleading, so maybe [g
On 11/13/18 4:09 PM, Vladimir Makarov wrote:
> On 11/13/2018 10:53 AM, Peter Bergner wrote:
>> I think with the above results, I think the patch is ready for review.
>> I'm attaching the latest updated patch below.
>>
>> Again, this passed bootstrap and regtesting
ected results.
>
> OK with the s/simple/swap/ change suggested by Richard.
Ok, I used operand_for_swap_move_operator like Richard suggested and also
did a similar change for resolve_operand_for_swap_move_operator to keep
things consistent. Now committed. Thanks!
Peter
86_64-linux.
Ok for mainline assuming the tests show no regressions?
Peter
gcc/
PR rtl-optimization/88033
* ira-lives.c (non_conflicting_reg_copy_p): Skip copies from a register
to itself. Use HARD_REGISTER_NUM_P.
gcc/testsuite/
PR rtl-optimization/
e "W" is only used
for the vector modes, I think we're ok here, aren't we?
>> I'll note I didn't change the vsx_mov_32bit pattern, since TImode
>> isn't supported with -m32. However, if you want, I could remove the
>> redundant "*r" <- "jwM" alternative there too?
>
> Yeah, please keep the patterns in synch.
Ok, I'll do the same thing and retest.
Peter
On 11/16/18 1:15 PM, Peter Bergner wrote:
> This is currently bootstrapping and regtesting on x86_64-linux.
> Ok for mainline assuming the tests show no regressions?
>
> gcc/
> PR rtl-optimization/88033
> * ira-lives.c (non_conflicting_reg_copy_p): Skip copi
On 11/16/18 11:06 AM, Segher Boessenkool wrote:
> On Tue, Nov 13, 2018 at 11:29:20AM -0600, Peter Bergner wrote:
>> I'll note I didn't change the vsx_mov_32bit pattern, since TImode
>> isn't supported with -m32. However, if you want, I could remove the
>> redun
On 11/19/18 1:17 PM, Vladimir Makarov wrote:
> On 11/16/2018 02:15 PM, Peter Bergner wrote:
>> PR88033 shows a problem when handling simple copies from a register to
>> itself:
>>
>> (insn (set (reg:DI NNN) (reg:DI NNN)))
>>
>> This was causing confusion
that.
Ok for mainline once bootstrap and regtesting are complete and clean?
Peter
gcc/
PR target/87496
* config/rs6000/rs6000.c (rs6000_option_override_internal): Disallow
-mabi=ieeelongdouble without both -mpopcntd and -mvsx.
gcc/testsuite/
PR target/87496
On 11/28/18 3:27 PM, Peter Bergner wrote:
> Ok for mainline once bootstrap and regtesting are complete and clean?
>
> Peter
>
>
> gcc/
> PR target/87496
> * config/rs6000/rs6000.c (rs6000_option_override_internal): Disallow
> -mabi=ieeelongdouble
On 11/29/18 11:26 AM, Segher Boessenkool wrote:
> On Wed, Nov 28, 2018 at 03:27:19PM -0600, Peter Bergner wrote:
>> PR87496 shows a bug where we ICE if we attempt to use -mabi=ieeelongdouble
>> and -mno-popcntd. The IEEE128 support requires full ISA 2.06 (aka POWER7)
>>
On 11/29/18 1:31 PM, Peter Bergner wrote:
> On 11/29/18 11:26 AM, Segher Boessenkool wrote:
>> On Wed, Nov 28, 2018 at 03:27:19PM -0600, Peter Bergner wrote:
>>> PR87496 shows a bug where we ICE if we attempt to use -mabi=ieeelongdouble
>>> and -mno-popcntd. The IEEE12
The -mdejagnu-cpu= option was added as a way for a test case to ensure a
particular -mcpu= option is used to compile the test, regardless of whether
the user attempts to override it (purposely or accidentally) via RUNTESTFLAGS.
This was well and good, but the ASM_CPU_SPEC was not updated to handle
ent
if the output operand is not early clobber or the input operand is known
to be a matching constraint.
This passed bootstrap and regression testing with no regressions on
both x86_64-linux and powerpc64le-linux. Ok for mainline?
Peter
gcc/
PR rtl-optimization/89313
*
regtesting on powerpc64le-linux with no
regressions. Ok for mainline?
Peter
gcc/
PR rtl-optimization/88845
* config/rs6000/rs6000.c (rs6000_emit_move_si_sf_subreg): Enable during
LRA.
* config/rs6000/rs6000.md (movsf_from_si): New expander; old insn and
I'd like to ping the following patch:
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01728.html
Peter
gcc/
PR rtl-optimization/89313
* function.c (matching_constraint_num): New static function.
(match_asm_constraints_1): Use it. Fixup white space and co
-mcpu" { powerpc*-*-* } { "-mcpu=*" } {
>> "-mcpu=power8" } } */
>> +/* { dg-options "-mcpu=power8 -O2" } */
>
> These two lines should now be just
>
> /* { dg-options "-mdejagnu-cpu=power8 -O2" } */
Ok, will update th
On 3/4/19 4:16 PM, Peter Bergner wrote:
> Index: gcc/config/rs6000/rs6000.c
> ===
> --- gcc/config/rs6000/rs6000.c(revision 269028)
> +++ gcc/config/rs6000/rs6000.c(working copy)
> @@
On 3/4/19 4:24 PM, Peter Bergner wrote:
> On 3/4/19 4:16 PM, Peter Bergner wrote:
>> Index: gcc/config/rs6000/rs6000.c
>> ===
>> --- gcc/config/rs6000/rs6000.c (revision 269028)
>> +++ gcc/config/rs6
n X constraint. For those alternatives,
LRA changes the scratch reg back to just a scratch when it's all done.
Peter
On 3/5/19 5:51 AM, Segher Boessenkool wrote:
> On Mon, Mar 04, 2019 at 06:41:16PM -0600, Peter Bergner wrote:
>> Like this. This bootstraps and regtests with no regressions. Do you prefer
>> this instead? If so, we'll need Vlad or Jeff or ... to approve the LRA
>> cha
#x27;9'))
> return strtoul (constraint, NULL, 10);
>
> return -1;
> }
Ok, changed. Thanks!
Peter
On 3/6/19 8:56 AM, Peter Bergner wrote:
> On 3/6/19 8:47 AM, Segher Boessenkool wrote:
>> Which means you can write it as just
>>
>> static int
>> matching_constraint_num (const char *constraint)
>> {
>> if (*constraint == '%')
>> c
On 3/25/19 3:36 PM, Jeff Law wrote:
> On 2/20/19 8:19 PM, Peter Bergner wrote:
>> gcc/
>> PR rtl-optimization/89313
>> * function.c (matching_constraint_num): New static function.
>> (match_asm_constraints_1): Use it. Fixup white space and comment.
>&g
Zdravím,
Obsah této posty je velmi duverný a legální. Jmenuji se Peter Wong, pracuji s
bankou tady v Hong Kongu. Rozhodl jsem se vás kontaktovat pro moznost
investovat do lukrativního podnikání ve va?í zemi. Jsem ochoten Vám nabídnout
40% investicního zisku jako muj obchodní partner.
Nase
ions=1, blocks=6, points=10
allocnos=6 (big 0), copies=2, conflicts=0, ranges=6
...
Ok for mainline once we hit stage1 again? Unless people want this now,
given it's only debug output used when -fdump-rtl-ira is used.
Peter
* ira-conflicts.c (print_allocno_co
On 4/16/19 12:47 PM, Peter Bergner wrote:
> The patch below fixes the issue not continuing if the allocno's conflict
> array is null and instead guarding the current conflict prints by that
> test. If the conflict array is null, we instead now print out simple
> empty conflic
On 4/17/19 12:57 PM, Jeff Law wrote:
> On 4/17/19 9:35 AM, Peter Bergner wrote:
>> * ira-conflicts.c (print_allocno_conflicts): Always print something,
>> even for allocno's with no conflicts.
>> (print_conflicts): Print an extra newline.
> OK. And
.
The patch below fixes that oversight.
I have confirmed we now assign pseudo p116 to r0 in the ARM test case
as well as a similar assignment issue on POWER.
This passed bootstrap and regtesting with no regressions on powerpc64le-linux.
Ok for mainline?
Peter
PR rtl-optimization/
On 4/18/19 4:39 PM, Vladimir Makarov wrote:
> On 4/18/19 11:24 AM, Peter Bergner wrote:
>> I have confirmed we now assign pseudo p116 to r0 in the ARM test case
>> as well as a similar assignment issue on POWER.
>>
>> This passed bootstrap and regtesting with no reg
401 - 500 of 1976 matches
Mail list logo
