Hi,
On Fri, 6 Jul 2007, Richard Guenther wrote:
Btw, is there a bug-report about the issue you are facing? Please
let's take this issue there.
There's now (32698), I kinda hoped it would be easier to fix. :)
bye, Roman
On Fri, 6 Jul 2007, Roman Zippel wrote:
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
For me both canonicalizations generate
movl8(%ecx,%edx,4), %eax
addl4(%ecx,%edx,4), %eax
Hmm, there seem to be other problems in this area as well.
Either add a p[i +
On Thu, 5 Jul 2007, Roman Zippel wrote:
Hi,
On Fri, 29 Jun 2007, Andrew Pinski wrote:
I'm not sure that's related, what's happening in my example is that the
call to fold_plusminus_mult_expr() defeats the optimization attempted in
pointer_int_sum(). If I use the patch below to
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
The code to fold_binary was added by:
r107218 | rguenth | 2005-11-19 03:29:10 -0800 (Sat, 19 Nov 2005) | 9 lines
2005-11-19 Richard Guenther [EMAIL PROTECTED]
PR middle-end/23294
* fold-const.c
On Thu, 5 Jul 2007, Roman Zippel wrote:
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
The code to fold_binary was added by:
r107218 | rguenth | 2005-11-19 03:29:10 -0800 (Sat, 19 Nov 2005) | 9
lines
2005-11-19 Richard Guenther [EMAIL PROTECTED]
PR
Hi,
On Thu, 5 Jul 2007, I wrote:
Exactly and that's why I think this transformation is done far too early.
It doesn't make sense that these two examples produce different code:
int foo1(int x)
{
return (x * 4) + 4;
}
int foo2(int x)
{
int y = x * 4;
return y + 4;
On Thu, 5 Jul 2007, Roman Zippel wrote:
Hi,
On Thu, 5 Jul 2007, I wrote:
Exactly and that's why I think this transformation is done far too early.
It doesn't make sense that these two examples produce different code:
int foo1(int x)
{
return (x * 4) + 4;
}
int foo2(int
On Thu, 5 Jul 2007, Roman Zippel wrote:
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
If there is anything to fix, then all those variants should produce
the same code, not just foo3 and foo4. So for these cases we should
make sure that value-numbering sees them as computing the
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
If there is anything to fix, then all those variants should produce
the same code, not just foo3 and foo4. So for these cases we should
make sure that value-numbering sees them as computing the same value
and extend combine to choose the
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
Well, that's always the nature of any canonicalization.
Well, I can't say that I agree with your canonicalization, but...
of course only tested on this particular testcase. It just shows
that it is possible to fix this in a generic way.
On 7/5/07, Richard Guenther [EMAIL PROTECTED] wrote:
On Thu, 5 Jul 2007, Roman Zippel wrote:
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
If there is anything to fix, then all those variants should produce
the same code, not just foo3 and foo4. So for these cases we should
make
On 7/5/07, Roman Zippel [EMAIL PROTECTED] wrote:
Hi,
On Thu, 5 Jul 2007, I wrote:
Exactly and that's why I think this transformation is done far too early.
It doesn't make sense that these two examples produce different code:
int foo1(int x)
{
return (x * 4) + 4;
}
int foo2(int
On Thu, 5 Jul 2007, Roman Zippel wrote:
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
Well, that's always the nature of any canonicalization.
Well, I can't say that I agree with your canonicalization, but...
of course only tested on this particular testcase. It just shows
that
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
How should this be optimized within the context of your canonicalization?
For example by making fold_plusminus_mult_expr do what its comment
suggest, No identical multiplicands; see if we can find a common
power-of-two factor ...
Can you
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
For me both canonicalizations generate
movl8(%ecx,%edx,4), %eax
addl4(%ecx,%edx,4), %eax
Hmm, there seem to be other problems in this area as well.
Either add a p[i + 3] to it to fool combine or try this:
int g(void);
On 7/5/07, Roman Zippel [EMAIL PROTECTED] wrote:
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
For me both canonicalizations generate
movl8(%ecx,%edx,4), %eax
addl4(%ecx,%edx,4), %eax
Hmm, there seem to be other problems in this area as well.
Either add a p[i +
Hi,
On Fri, 29 Jun 2007, Andrew Pinski wrote:
I'm not sure that's related, what's happening in my example is that the
call to fold_plusminus_mult_expr() defeats the optimization attempted in
pointer_int_sum(). If I use the patch below to restrict the condition, my
problem is fixed, but
Hi,
On Thu, 28 Jun 2007, [EMAIL PROTECTED] wrote:
Roman Zippel [EMAIL PROTECTED] wrote on 06/28/2007 07:54:43 PM:
Hi,
Notice that it generates the (i + 1) * 4 instead of (i * 4) + 4 as with
the other cases. While I tried to debug this I narrowed it down to the
changes in
On 6/29/07, Roman Zippel [EMAIL PROTECTED] wrote:
Hi,
On Thu, 28 Jun 2007, [EMAIL PROTECTED] wrote:
Roman Zippel [EMAIL PROTECTED] wrote on 06/28/2007 07:54:43 PM:
Hi,
Notice that it generates the (i + 1) * 4 instead of (i * 4) + 4 as with
the other cases. While I tried to debug this I
Hi,
On Fri, 15 Jun 2007, [EMAIL PROTECTED] wrote:
This patch merges in the pointer_plus branch. Hopefully I did not mess
anything up.
I found a small regression caused by this, e.g.:
int g(void);
void f(int *p, int i)
{
p[i] = g();
p[i + 2] = g();
p[i + 1] = g();
Roman Zippel [EMAIL PROTECTED] wrote on 06/28/2007 07:54:43 PM:
Hi,
Notice that it generates the (i + 1) * 4 instead of (i * 4) + 4 as with
the other cases. While I tried to debug this I narrowed it down to the
changes in fold_binary(), but I don't really know how to fix this, so
I could
21 matches
Mail list logo
