On 05/16/2015 07:55 PM, Hans-Peter Nilsson wrote:
On Sat, 16 May 2015, Segher Boessenkool wrote:
On Sat, May 16, 2015 at 12:36:38PM -0400, Hans-Peter Nilsson wrote:
On Sat, 16 May 2015, Segher Boessenkool wrote:
On Fri, May 15, 2015 at 10:40:48PM -0400, Hans-Peter Nilsson wrote:
I confess
On Sat, May 16, 2015 at 09:55:08PM -0400, Hans-Peter Nilsson wrote:
With a plus or minus combine would always write it as a mult.
I don't think any other pass would create this combination. I
haven't tested it though.
Ports probably also generate that internally at various RTL
passes,
On Sun, 17 May 2015, Segher Boessenkool wrote:
I used http://git.infradead.org/users/segher/buildall.git; it has
a README. I see that doc is a little out of date, I'll update.
(git: not http: for cloning) Thanks, looks useful.
Hm, maybe we already mention this in the wiki...
- add a
On Sat, May 16, 2015 at 12:36:38PM -0400, Hans-Peter Nilsson wrote:
On Sat, 16 May 2015, Segher Boessenkool wrote:
On Fri, May 15, 2015 at 10:40:48PM -0400, Hans-Peter Nilsson wrote:
I confess the test-case-guarded addi pattern should have been
expressed with a shift in addition to the
On Fri, May 15, 2015 at 10:40:48PM -0400, Hans-Peter Nilsson wrote:
I confess the test-case-guarded addi pattern should have been
expressed with a shift in addition to the multiplication.
But they wouldn't ever match so they might very well have bitrotted
by now :-(
(In
addition to as the
On Sat, 16 May 2015, Segher Boessenkool wrote:
On Fri, May 15, 2015 at 10:40:48PM -0400, Hans-Peter Nilsson wrote:
I confess the test-case-guarded addi pattern should have been
expressed with a shift in addition to the multiplication.
But they wouldn't ever match so they might very well
On Sat, 16 May 2015, Segher Boessenkool wrote:
On Sat, May 16, 2015 at 12:36:38PM -0400, Hans-Peter Nilsson wrote:
On Sat, 16 May 2015, Segher Boessenkool wrote:
On Fri, May 15, 2015 at 10:40:48PM -0400, Hans-Peter Nilsson wrote:
I confess the test-case-guarded addi pattern should have
On Fri, 1 May 2015, Segher Boessenkool wrote:
On Wed, Apr 29, 2015 at 12:03:35PM -0500, Segher Boessenkool wrote:
On Wed, Apr 29, 2015 at 09:25:21AM +, Kumar, Venkataramanan wrote:
diff --git a/gcc/combine.c b/gcc/combine.c
index 5c763b4..945abdb 100644
--- a/gcc/combine.c
+++
On Tue, 2015-05-12 at 05:21 +, Kumar, Venkataramanan wrote:
Hi Steve,
Yes this is expected. As Segher pointed out, we need to change .md patterns
in
target to be based on shifts instead of mults.
Regards,
Venkat.
Here is my patch to change this. I tested it with the
: [RFC]: Remove Mem/address type assumption in combiner
On Tue, 2015-05-12 at 05:21 +, Kumar, Venkataramanan wrote:
Hi Steve,
Yes this is expected. As Segher pointed out, we need to change .md
patterns in target to be based on shifts instead of mults.
Regards,
Venkat.
Here
Hi Steve,
On Mon, May 11, 2015 at 10:50:02AM -0700, Steve Ellcey wrote:
This patch broke a number of MIPS tests, specifically mips32r6 tests
that look for the lsa instruction (load scaled address) which shifts one
register and then adds it to a second register. I am not sure if this
needs to
Jeff Law l...@redhat.com writes:
On 05/11/2015 01:46 PM, Jeff Law wrote:
On 05/11/2015 01:44 PM, Steve Ellcey wrote:
On Mon, 2015-05-11 at 13:22 -0500, Segher Boessenkool wrote:
Hi Steve,
On Mon, May 11, 2015 at 10:50:02AM -0700, Steve Ellcey wrote:
This patch broke a number of MIPS
On 05/11/2015 01:46 PM, Jeff Law wrote:
On 05/11/2015 01:44 PM, Steve Ellcey wrote:
On Mon, 2015-05-11 at 13:22 -0500, Segher Boessenkool wrote:
Hi Steve,
On Mon, May 11, 2015 at 10:50:02AM -0700, Steve Ellcey wrote:
This patch broke a number of MIPS tests, specifically mips32r6 tests
that
On Mon, May 11, 2015 at 08:16:41PM +, Matthew Fortune wrote:
Does this patch effectively change the canonicalization rules? The following
Still exists in md.texi:
@item
Within address computations (i.e., inside @code{mem}), a left shift is
converted into the appropriate multiplication
Segher Boessenkool seg...@kernel.crashing.org writes:
On Mon, May 11, 2015 at 08:16:41PM +, Matthew Fortune wrote:
Does this patch effectively change the canonicalization rules? The
following Still exists in md.texi:
@item
Within address computations (i.e., inside @code{mem}), a
On 05/11/2015 01:44 PM, Steve Ellcey wrote:
On Mon, 2015-05-11 at 13:22 -0500, Segher Boessenkool wrote:
Hi Steve,
On Mon, May 11, 2015 at 10:50:02AM -0700, Steve Ellcey wrote:
This patch broke a number of MIPS tests, specifically mips32r6 tests
that look for the lsa instruction (load scaled
On Mon, 2015-05-11 at 13:22 -0500, Segher Boessenkool wrote:
Hi Steve,
On Mon, May 11, 2015 at 10:50:02AM -0700, Steve Ellcey wrote:
This patch broke a number of MIPS tests, specifically mips32r6 tests
that look for the lsa instruction (load scaled address) which shifts one
register and
: Segher Boessenkool; Jeff Law (l...@redhat.com); gcc-patches@gcc.gnu.org;
maxim.kuvyr...@linaro.org; Matthew Fortune; clm
Subject: RE: [RFC]: Remove Mem/address type assumption in combiner
On Thu, 2015-05-07 at 11:01 +, Kumar, Venkataramanan wrote:
Hi Segher,
Thank you I committed
On Thu, 2015-05-07 at 11:01 +, Kumar, Venkataramanan wrote:
Hi Segher,
Thank you I committed as r222874.
Ref: https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=222874
Regards,
Venkat.
Venkat,
This patch broke a number of MIPS tests, specifically mips32r6 tests
that look for
(l...@redhat.com); gcc-patches@gcc.gnu.org;
maxim.kuvyr...@linaro.org
Subject: Re: [RFC]: Remove Mem/address type assumption in combiner
On Tue, May 05, 2015 at 04:14:03PM +, Kumar, Venkataramanan wrote:
Hi Segher,
Thank you for testing the patch and approving it.
Before I commit
: Friday, May 01, 2015 8:48 PM
To: Kumar, Venkataramanan
Cc: Jeff Law (l...@redhat.com); gcc-patches@gcc.gnu.org;
maxim.kuvyr...@linaro.org
Subject: Re: [RFC]: Remove Mem/address type assumption in combiner
On Wed, Apr 29, 2015 at 12:03:35PM -0500, Segher Boessenkool wrote:
On Wed, Apr 29, 2015 at 09
On Tue, May 05, 2015 at 04:14:03PM +, Kumar, Venkataramanan wrote:
Hi Segher,
Thank you for testing the patch and approving it.
Before I commit it, I wanted to check with you on the changelog entry.
Please find the updated patch with the changelog entry.
I have just removed the
On Wed, Apr 29, 2015 at 12:03:35PM -0500, Segher Boessenkool wrote:
On Wed, Apr 29, 2015 at 09:25:21AM +, Kumar, Venkataramanan wrote:
diff --git a/gcc/combine.c b/gcc/combine.c
index 5c763b4..945abdb 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -7703,8 +7703,6 @@
On 04/29/2015 11:03 AM, Segher Boessenkool wrote:
Right. It would be good if you could find out for what targets it matters.
The thing is, if a target expects only the patterns as combine used to make
them, it will regress (as you've seen on aarch64); but it will regress
_silently_. Which
On 04/29/2015 03:25 AM, Kumar, Venkataramanan wrote:
Hi Jeff/Segher,
When we see an RTX code with PLUS or MINUS then it is treated as MEM/address
type (we are inside address RTX).
Is there any significance on that assumption? I removed this assumption and
the test case in the PR 63949
On 04/29/2015 03:25 AM, Kumar, Venkataramanan wrote:
Hi Jeff/Segher,
Restarting the discussion on the GCC combiner assumption about Memory/address
type.
Ref: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01298.html
https://gcc.gnu.org/ml/gcc/2015-04/msg00028.html
Regards,
Venkat.
PS: I am
Hello Venkat,
On Wed, Apr 29, 2015 at 09:25:21AM +, Kumar, Venkataramanan wrote:
diff --git a/gcc/combine.c b/gcc/combine.c
index 5c763b4..945abdb 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -7703,8 +7703,6 @@ make_compound_operation (rtx x, enum rtx_code in_code)
but once
27 matches
Mail list logo
