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 think I have the reg
>> numbers for t
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 think I have the reg
> numbers for the other architectures defined correctly.
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-optimization/
On 11/7/18 11:36 AM, Jeff Law wrote:
> I was referring to a more fundamental check in the IL checkers.
Yes, I understood that. I was just replying to Segher's specific issue
with this code. I do plan on looking at adding IL verifier checks for
subregs of subregs like you requested.
> Segher ma
On 11/7/18 9:29 AM, Peter Bergner wrote:
> On 11/6/18 6:14 PM, Segher Boessenkool wrote:
>> Or more general, that what is inside the subreg is a reg, because the
>> code does rely on that.
>
> I think you mean to beef up the following from:
>
> + if (HARD_REGISTER_P (nop_r
On 11/6/18 6:14 PM, Segher Boessenkool wrote:
> Or more general, that what is inside the subreg is a reg, because the
> code does rely on that.
I think you mean to beef up the following from:
+ if (HARD_REGISTER_P (nop_reg)
+ && REG_USERVAR_
On Tue, Nov 06, 2018 at 01:27:58PM -0700, Jeff Law wrote:
> So the one worry I have/had in this code is nested subregs. My
> recollection is they do happen in rare cases. But I can also find a
> reference where Jim W. has indicated they're invalid (and I absolutely
> trust Jim on this kind of hi
On 10/27/18 10:24 AM, Peter Bergner wrote:
> 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 su
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
powerpc64le-li
On 10/22/18 6:20 PM, Segher Boessenkool wrote:
> Hi peter,
>
> On Mon, Oct 22, 2018 at 06:40:58PM -0500, Peter Bergner wrote:
>> --- gcc/function.c (revision 265399)
>> +++ gcc/function.c (working copy)
>> @@ -6453,6 +6453,13 @@ match_asm_constraints_1 (rtx_insn *insn,
>>|| !general_op
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)
>> + && HARD_REGISTER_P (input)
>> + && REGNO (o
Hi peter,
On Mon, Oct 22, 2018 at 06:40:58PM -0500, Peter Bergner wrote:
> --- gcc/function.c(revision 265399)
> +++ gcc/function.c(working copy)
> @@ -6453,6 +6453,13 @@ match_asm_constraints_1 (rtx_insn *insn,
> || !general_operand (input, GET_MODE (output)))
> continue;
>
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's automatically picked up :-) In fact,
>
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 trunk are triggers, though in re
On 10/19/2018 05:16 PM, Peter Bergner wrote:
Vlad, Jeff and Segher,
I think I have determined what is happening with the aarch64 test case that
is failing after my r264897 commit. It appears my patch is just exposing
an issue in lra-constraints.c:process_alt_operands() when processing an ins
On 10/19/18 4:39 PM, Peter Bergner wrote:
> 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 hav
On Fri, Oct 19, 2018 at 05:39:07PM -0500, Peter Bergner wrote:
> 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
Hi Peter,
On Fri, Oct 19, 2018 at 04:16:12PM -0500, Peter Bergner wrote:
> In lra-constraints.c:process_alt_operands(), we notice that pseudo 92 is
> assigned to x1 and that an early clobber operand is also assigned to x1, or
> rather, that it uses x1 explicitly. This is enough to trigger reload(
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 something soon.
[snip]
> * lra-constrai
Vlad, Jeff and Segher,
I think I have determined what is happening with the aarch64 test case that
is failing after my r264897 commit. It appears my patch is just exposing
an issue in lra-constraints.c:process_alt_operands() when processing an insn
with early clobber operands. Jeff & Segher, I h
20 matches
Mail list logo
