On Wed, 2 Nov 2011, William J. Schmidt wrote:
> On Wed, 2011-11-02 at 12:55 +0100, Richard Guenther wrote:
> > On Sun, 30 Oct 2011, William J. Schmidt wrote:
> >
> > > Ping.
> > >
> > > On Mon, 2011-10-24 at 08:38 -0500, William J. Schmidt wrote:
> > > > OK, I've removed the pointer-arithmetic c
On Wed, 2011-11-02 at 12:55 +0100, Richard Guenther wrote:
> On Sun, 30 Oct 2011, William J. Schmidt wrote:
>
> > Ping.
> >
> > On Mon, 2011-10-24 at 08:38 -0500, William J. Schmidt wrote:
> > > OK, I've removed the pointer-arithmetic case from expand, to be handled
> > > later by straight-line s
On Sun, 30 Oct 2011, William J. Schmidt wrote:
> Ping.
>
> On Mon, 2011-10-24 at 08:38 -0500, William J. Schmidt wrote:
> > OK, I've removed the pointer-arithmetic case from expand, to be handled
> > later by straight-line strength reduction. Here's the patch to deal
> > with just the specific p
Ping.
On Mon, 2011-10-24 at 08:38 -0500, William J. Schmidt wrote:
> OK, I've removed the pointer-arithmetic case from expand, to be handled
> later by straight-line strength reduction. Here's the patch to deal
> with just the specific pattern of PR46556 (which will also eventually be
> handled b
OK, I've removed the pointer-arithmetic case from expand, to be handled
later by straight-line strength reduction. Here's the patch to deal
with just the specific pattern of PR46556 (which will also eventually be
handled by strength reduction, but not as quickly).
(FYI, I've been thinking through
On Fri, Oct 21, 2011 at 2:22 PM, William J. Schmidt
wrote:
>
>
> On Fri, 2011-10-21 at 11:26 +0200, Richard Guenther wrote:
>> On Tue, Oct 18, 2011 at 4:14 PM, William J. Schmidt
>> wrote:
>
>
>
>> > +
>> > + /* We don't use get_def_for_expr for S1 because TER doesn't forward
>> > + S1 in s
On Fri, 2011-10-21 at 11:26 +0200, Richard Guenther wrote:
> On Tue, Oct 18, 2011 at 4:14 PM, William J. Schmidt
> wrote:
> > +
> > + /* We don't use get_def_for_expr for S1 because TER doesn't forward
> > + S1 in some situations where this transform is useful, such as
> > + when S1
On Tue, Oct 18, 2011 at 4:14 PM, William J. Schmidt
wrote:
> Greetings,
>
> Here is a new revision of the tree portions of this patch. I moved the
> pattern recognizer to expand, and added additional logic to look for the
> same pattern in gimple form. I added two more tests to verify the new
>
Greetings,
Here is a new revision of the tree portions of this patch. I moved the
pattern recognizer to expand, and added additional logic to look for the
same pattern in gimple form. I added two more tests to verify the new
logic.
I didn't run into any problems with the RTL CSE phases. I can'
Richard Guenther writes:
>> You should be able to recreate the problem yourself by using
>> --enable-languages=go when you run configure.
>
> I suppose you can create a C testcase?
I don't know whether I can, as the Go frontend is generating
VIEW_CONVERT_EXPR here. I will try to take another lo
On Tue, 11 Oct 2011, Ian Lance Taylor wrote:
> On Tue, Oct 11, 2011 at 4:40 AM, Richard Guenther wrote:
>
> > this function misses to transfer TREE_THIS_NOTRAP which is supposed
> > to be set on the base of old_ref or any contained ARRAY[_RANGE]_REF.
> > If you make the function generic please a
Thanks -- I will back that line out for now and investigate. Regression
test was fine for the languages we normally build, but go and ada aren't
among those. Sorry for the trouble!
On Tue, 2011-10-11 at 14:00 -0700, Ian Lance Taylor wrote:
> On Tue, Oct 11, 2011 at 4:40 AM, Richard Guenther wro
On Tue, Oct 11, 2011 at 4:40 AM, Richard Guenther wrote:
> this function misses to transfer TREE_THIS_NOTRAP which is supposed
> to be set on the base of old_ref or any contained ARRAY[_RANGE]_REF.
> If you make the function generic please adjust it to at least do ...
> ...
>
> TREE_THIS
On Tue, 2011-10-11 at 09:12 -0500, William J. Schmidt wrote:
> > The pattern matching is still very ad-hoc and doesn't consider
> > statements that feed the base address. There is conceptually
> > no difference between p->a[n] and *(p + n * 4).
>
> That's true. Since we abandoned the general ad
Hi Richard,
Thanks for the comments -- a few responses below.
On Tue, 2011-10-11 at 13:40 +0200, Richard Guenther wrote:
> On Sat, 8 Oct 2011, William J. Schmidt wrote:
>
>
> > + c4 = uhwi_to_double_int (bitpos / BITS_PER_UNIT);
>
> You don't verify that bitpos % BITS_PER_UNIT is zero anyw
On 10/11/2011 01:40 PM, Richard Guenther wrote:
The pattern matching is still very ad-hoc and doesn't consider
statements that feed the base address. There is conceptually
no difference between p->a[n] and *(p + n * 4). You placed this
lowering in reassoc to catch CSE opportunities with DOM, ri
On Sat, 8 Oct 2011, William J. Schmidt wrote:
> Greetings,
>
> Here are the revised changes for the tree portions of the patch. I've
> attempted to resolve all comments to date on those portions. Per
> Steven's comment, I moved copy_ref_info into tree-ssa-address.c; let me
> know if there's a b
Greetings,
Here are the revised changes for the tree portions of the patch. I've
attempted to resolve all comments to date on those portions. Per
Steven's comment, I moved copy_ref_info into tree-ssa-address.c; let me
know if there's a better place, or whether you'd prefer to leave it
where it w
On Fri, 2011-10-07 at 11:17 +0200, Paolo Bonzini wrote:
> On 10/07/2011 10:00 AM, Richard Guenther wrote:
> > It's a reasonable plan - you'd have to introduce a late reassoc
> > pass though. Can you separate out the RTL fwprop changes? So
> > we can iterate over the tree parts separately.
>
> Th
On 10/07/2011 10:00 AM, Richard Guenther wrote:
It's a reasonable plan - you'd have to introduce a late reassoc
pass though. Can you separate out the RTL fwprop changes? So
we can iterate over the tree parts separately.
That's indeed better, also because they became CSE changes.
Paolo
On Thu, 6 Oct 2011, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/06/11 04:13, Richard Guenther wrote:
>
> >
> > People have already commented on pieces, so I'm looking only at the
> > tree-ssa-reassoc.c pieces (did you consider piggy-backing on IVOPTs
> > instead?
On Thu, 6 Oct 2011, William J. Schmidt wrote:
> On Thu, 2011-10-06 at 16:16 +0200, Richard Guenther wrote:
>
>
>
> >
> > Doh, I thought you were matching gimple stmts that do the address
> > computation. But now I see you are matching the tree returned from
> > get_inner_reference. So no nee
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/06/11 12:02, William J. Schmidt wrote:
> On Thu, 2011-10-06 at 11:35 -0600, Jeff Law wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 10/06/11 04:13, Richard Guenther wrote:
>>
>>>
>>> People have already commented on pieces, s
On Thu, 2011-10-06 at 11:35 -0600, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/06/11 04:13, Richard Guenther wrote:
>
> >
> > People have already commented on pieces, so I'm looking only at the
> > tree-ssa-reassoc.c pieces (did you consider piggy-backing on IVOPT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/06/11 04:13, Richard Guenther wrote:
>
> People have already commented on pieces, so I'm looking only at the
> tree-ssa-reassoc.c pieces (did you consider piggy-backing on IVOPTs
> instead? The idea is to expose additional CSE opportunities,
>
On Thu, 2011-10-06 at 16:16 +0200, Richard Guenther wrote:
>
> Doh, I thought you were matching gimple stmts that do the address
> computation. But now I see you are matching the tree returned from
> get_inner_reference. So no need to check anything for that case.
>
> But that keeps me wonde
On Thu, 6 Oct 2011, William J. Schmidt wrote:
> On Thu, 2011-10-06 at 12:13 +0200, Richard Guenther wrote:
> > People have already commented on pieces, so I'm looking only
> > at the tree-ssa-reassoc.c pieces (did you consider piggy-backing
> > on IVOPTs instead? The idea is to expose additional
On Thu, 2011-10-06 at 12:13 +0200, Richard Guenther wrote:
> People have already commented on pieces, so I'm looking only
> at the tree-ssa-reassoc.c pieces (did you consider piggy-backing
> on IVOPTs instead? The idea is to expose additional CSE
> opportunities, right? So it's sort-of a strength
On Thu, 2011-10-06 at 09:47 +0200, Paolo Bonzini wrote:
> And IIUC the other address is based on pseudo 125 as well, but the
> combination is (plus (plus (reg 126) (reg 128)) (const_int X)) and
> cannot be represented on ppc. I think _this_ is the problem, so I'm
> afraid your patch could cause
On Wed, 5 Oct 2011, William J. Schmidt wrote:
> This patch addresses the poor code generation in PR46556 for the
> following code:
>
> struct x
> {
> int a[16];
> int b[16];
> int c[16];
> };
>
> extern void foo (int, int, int);
>
> void
> f (struct x *p, unsigned int n)
> {
> foo (p->a
On 10/05/2011 10:16 PM, William J. Schmidt wrote:
OK, I see. If there's a better place downstream to make a swizzle, I'm
certainly fine with that.
I disabled locally_poor_mem_replacement and added some dump information
in should_replace_address to show the costs for the replacement I'm
trying t
On Wed, 2011-10-05 at 21:01 +0200, Paolo Bonzini wrote:
> On 10/05/2011 07:22 PM, William J. Schmidt wrote:
> > I don't know off the top of my head -- I'll have to gather that
> > information. The issue is that the profitability is really
> > context-sensitive, so just the isolated costs of insns
On 10/05/2011 07:22 PM, William J. Schmidt wrote:
I don't know off the top of my head -- I'll have to gather that
information. The issue is that the profitability is really
context-sensitive, so just the isolated costs of insns aren't enough.
The forward propagation of the add into (mem (reg REG
On Wed, 2011-10-05 at 18:21 +0200, Paolo Bonzini wrote:
> On 10/05/2011 06:13 PM, William J. Schmidt wrote:
> > One other general question about the pattern-match transformation: Is
> > this an appropriate transformation for all targets, or should it be
> > somehow gated on available addressing mo
On Wed, 2011-10-05 at 18:29 +0200, Steven Bosscher wrote:
> On Wed, Oct 5, 2011 at 6:13 PM, William J. Schmidt
> wrote:
> >* tree-ssa-loop-ivopts.c (copy_ref_info): Remove static token.
>
> Rather than this, why not move the function to common code somewhere?
>
> Ciao!
> Steven
An alter
On Wed, Oct 5, 2011 at 6:13 PM, William J. Schmidt
wrote:
> * tree-ssa-loop-ivopts.c (copy_ref_info): Remove static token.
Rather than this, why not move the function to common code somewhere?
Ciao!
Steven
On 10/05/2011 06:13 PM, William J. Schmidt wrote:
One other general question about the pattern-match transformation: Is
this an appropriate transformation for all targets, or should it be
somehow gated on available addressing modes on the target processor?
Bootstrapped and regression tested on
This patch addresses the poor code generation in PR46556 for the
following code:
struct x
{
int a[16];
int b[16];
int c[16];
};
extern void foo (int, int, int);
void
f (struct x *p, unsigned int n)
{
foo (p->a[n], p->c[n], p->b[n]);
}
Prior to the fix for PR32698, gcc calculated the off
38 matches
Mail list logo
