Jeff Law writes:
> diff --git a/gcc/testsuite/g++.dg/pr60648.C b/gcc/testsuite/g++.dg/pr60648.C
> new file mode 100644
> index 000..80c0561
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/pr60648.C
> @@ -0,0 +1,73 @@
> +/* { dg-do compile } */
> +/* { dg-do compile { target i?86-*-* x86_64-*-* }
On Fri, Mar 28, 2014 at 07:12:26PM +0100, Jakub Jelinek wrote:
> On Fri, Mar 28, 2014 at 12:04:00PM -0600, Jeff Law wrote:
> > Here's the updated patch. It uses simplify_gen_binary in expr.c to
> > simplify the address expression as we're building it. It also uses
> > copy_addr_to_reg in the x86
On Fri, Mar 28, 2014 at 12:04:00PM -0600, Jeff Law wrote:
> Here's the updated patch. It uses simplify_gen_binary in expr.c to
> simplify the address expression as we're building it. It also uses
> copy_addr_to_reg in the x86 backend to avoid the possibility of
> generating non-canonical RTL ther
On 03/26/14 12:28, Jakub Jelinek wrote:
On Wed, Mar 26, 2014 at 12:17:43PM -0600, Jeff Law wrote:
On 03/26/14 12:12, Jakub Jelinek wrote:
On Wed, Mar 26, 2014 at 11:02:48AM -0600, Jeff Law wrote:
Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
Verified it fixes the original and
On Thu, Mar 27, 2014 at 10:17:26AM -0600, Jeff Law wrote:
> >Did you mean Jeff's original change, or say:
> >--- gcc/config/i386/i386.c 2014-03-20 17:41:45.917689676 +0100
> >+++ gcc/config/i386/i386.c 2014-03-27 14:47:21.876254288 +0100
> >@@ -13925,13 +13925,13 @@ ix86_legitimize_address (rtx
On 03/27/14 07:51, Jakub Jelinek wrote:
On Wed, Mar 26, 2014 at 09:53:47PM +, Richard Sandiford wrote:
Richard Henderson writes:
On 03/26/2014 12:40 PM, Jakub Jelinek wrote:
On Wed, Mar 26, 2014 at 01:32:44PM -0600, Jeff Law wrote:
On 03/26/14 12:28, Jakub Jelinek wrote:
(mult:SI (const
On 03/26/14 15:53, Richard Sandiford wrote:
Richard Henderson writes:
On 03/26/2014 12:40 PM, Jakub Jelinek wrote:
On Wed, Mar 26, 2014 at 01:32:44PM -0600, Jeff Law wrote:
On 03/26/14 12:28, Jakub Jelinek wrote:
(mult:SI (const_int 0) (const_int 4)) is IMHO far from being canonical.
And, I'
On 03/27/2014 06:51 AM, Jakub Jelinek wrote:
> Did you mean Jeff's original change, or say:
> --- gcc/config/i386/i386.c2014-03-20 17:41:45.917689676 +0100
> +++ gcc/config/i386/i386.c2014-03-27 14:47:21.876254288 +0100
> @@ -13925,13 +13925,13 @@ ix86_legitimize_address (rtx x, rtx oldx
>
On Wed, Mar 26, 2014 at 09:53:47PM +, Richard Sandiford wrote:
> Richard Henderson writes:
> > On 03/26/2014 12:40 PM, Jakub Jelinek wrote:
> >> On Wed, Mar 26, 2014 at 01:32:44PM -0600, Jeff Law wrote:
> >>> On 03/26/14 12:28, Jakub Jelinek wrote:
> (mult:SI (const_int 0) (const_int 4))
Richard Henderson writes:
> On 03/26/2014 12:40 PM, Jakub Jelinek wrote:
>> On Wed, Mar 26, 2014 at 01:32:44PM -0600, Jeff Law wrote:
>>> On 03/26/14 12:28, Jakub Jelinek wrote:
(mult:SI (const_int 0) (const_int 4)) is IMHO far from being canonical.
And, I'd say it is likely other target
On 03/26/2014 12:40 PM, Jakub Jelinek wrote:
> On Wed, Mar 26, 2014 at 01:32:44PM -0600, Jeff Law wrote:
>> On 03/26/14 12:28, Jakub Jelinek wrote:
>>> (mult:SI (const_int 0) (const_int 4)) is IMHO far from being canonical.
>>> And, I'd say it is likely other target legitimization hooks would also
On Mar 26, 2014, at 11:33 AM, Jeff Law wrote:
> On 03/26/14 12:28, Jakub Jelinek wrote:
>> On Wed, Mar 26, 2014 at 12:17:43PM -0600, Jeff Law wrote:
>>> On 03/26/14 12:12, Jakub Jelinek wrote:
On Wed, Mar 26, 2014 at 11:02:48AM -0600, Jeff Law wrote:
> Bootstrapped and regression tested o
On Wed, Mar 26, 2014 at 01:32:44PM -0600, Jeff Law wrote:
> On 03/26/14 12:28, Jakub Jelinek wrote:
> >(mult:SI (const_int 0) (const_int 4)) is IMHO far from being canonical.
> >And, I'd say it is likely other target legitimization hooks would also try
> >to simplify it similarly.
> >simplify_gen_b
On 03/26/14 12:28, Jakub Jelinek wrote:
(mult:SI (const_int 0) (const_int 4)) is IMHO far from being canonical.
And, I'd say it is likely other target legitimization hooks would also try
to simplify it similarly.
simplify_gen_binary is used in several other places during expansion,
so I don't see
On Wed, Mar 26, 2014 at 12:17:43PM -0600, Jeff Law wrote:
> On 03/26/14 12:12, Jakub Jelinek wrote:
> >On Wed, Mar 26, 2014 at 11:02:48AM -0600, Jeff Law wrote:
> >>Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
> >>Verified it fixes the original and reduced testcase.
> >
> >Note,
On 03/26/14 12:28, Jakub Jelinek wrote:
On Wed, Mar 26, 2014 at 12:17:43PM -0600, Jeff Law wrote:
On 03/26/14 12:12, Jakub Jelinek wrote:
On Wed, Mar 26, 2014 at 11:02:48AM -0600, Jeff Law wrote:
Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
Verified it fixes the original and
On 03/26/14 12:12, Jakub Jelinek wrote:
On Wed, Mar 26, 2014 at 11:02:48AM -0600, Jeff Law wrote:
Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
Verified it fixes the original and reduced testcase.
Note, the testcase is missing from your patch.
But I'd question if this is the
On Wed, Mar 26, 2014 at 11:02:48AM -0600, Jeff Law wrote:
> Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
> Verified it fixes the original and reduced testcase.
Note, the testcase is missing from your patch.
But I'd question if this is the right place to canonicalize it.
The non
The x86 backend can generate non-canonical RTL when it simplifies
address expressions.
In particular addresses which have the form
(plus (mult) (A) (B) (label_ref))
If the multiplication can be simplified to a constant, the x86 backend
will end up generating
(plus (constant) (label_ref))
19 matches
Mail list logo
