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
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(v
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 ..."
>
>
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.
le
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 in
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;
> retur
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
> > What makes "(i + 1) * 4" the canonical form of "(i * 4) + 4" compared to
> > other expressions like "(i * 4) + 8"?
>
> It's an arbitrary decision by fold. For (i + 2) * 4 the canonical form
> is (i * 4) + 8. For (i * j) + j the canonical for
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-c
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
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
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()
Hi,
On Fri, 22 Jun 2007, Kenneth Zadeck wrote:
> > Index: gcc/gcc/reg-stack.c
> > ===
> > --- gcc.orig/gcc/reg-stack.c
> > +++ gcc/gcc/reg-stack.c
> > @@ -2316,6 +2316,12 @@ subst_stack_regs (rtx insn, stack regsta
> >if (NOTE_P
Hi,
On Wed, 20 Jun 2007, I wrote:
> Index: gcc/df-problems.c
> ===
> --- gcc/df-problems.c (revision 125811)
> +++ gcc/df-problems.c (working copy)
> @@ -1574,7 +1574,7 @@
>/* Call-clobbered registers die across exception and cal
Hi,
On Wed, 20 Jun 2007, Paolo Bonzini wrote:
> > This is one of the places where i slavishly copied what flow did. if
> > you want to change this, go test it on at least 7 platforms and fix all
> > of the problems that it causes.
>
> I see. Can one of you recap how it relates to the m68k probl
Hi,
On Wed, 20 Jun 2007, Kenneth Zadeck wrote:
> If we add the dead note there we are asserting that the value is
> modified by the caller. however it might not be and someone could write
> a piece of asm right after the call to use that reg if the person knew
> that the reg was not modified by t
Hi,
On Wed, 20 Jun 2007, Kenneth Zadeck wrote:
> > I don't understand, wouldn't the consertive approach be that the value
> > simply doesn't survive?
> >
> No, the conservative is that we do not know anything. it could be
> destroyed and it could not be destroyed.
What is the value of this? I
Hi,
On Wed, 20 Jun 2007, Kenneth Zadeck wrote:
> For certain regs, the subroutine may or may not modify the value. The
> better information alluded to is information that one might get by doing
> interprocedural analysis. Without such information you have to assume
> that the value may or may n
Hi,
On Tue, 19 Jun 2007, Kenneth Zadeck wrote:
> The reason that there is no reg_dead not in the last use (insn 45)
> before the sib_call (insn 46) is that there is no def for r0 in the
> sibcall (insn 46) and r0 is live at the end of the block.
>
> This of course changes the question to not wh
Hi,
On Tue, 19 Jun 2007, Kenneth Zadeck wrote:
> roman do i need any patches to apply before trying this.
None should be needed, but this one can't hurt:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01247.html
> also what are
> the config options i need?
I use --target=m68k-linux-gnu --enable
Hi,
m68k currently doesn't bootstrap, which I think is dataflow related, the
whole precompiled file is at http://www.xs4all.nl/~zippel/expmed.i.gz, but
the small test below should be enough to demonstrate the problem
(although it doesn't crash):
int fi1(int);
int fi2(int);
void *fp1(int, void
Hi,
On Fri, 1 Jun 2007, Ian Lance Taylor wrote:
> I don't know the answer. But I do know that you need to think about
> -fasynchronous-unwind-tables, and you need to think about how your
> kernel handles registers when calling a handler, and you need to think
> about what unwind information is a
Hi,
While working on a vdso for Linux/m68k I stumbled again on a problem, I
already had with the fallback unwind handler in gcc, where I'd like to
hear some opinions.
I'm looking at the i386 unwind handler and that doesn't bother to restore
any fp registers. On m68k it's a little more difficult
Hi,
On Fri, 11 May 2007, Paolo Bonzini wrote:
> First of all, scrap my other message...
>
> > There was a debate several months ago on this issue: how much should the
> > df scanner be a theorem prover with respect to how many bits survive an
> > operation.
> > For instance, I could easily add t
Hi,
On Fri, 11 May 2007, Kenneth Zadeck wrote:
> There was a debate several months ago on this issue: how much should the
> df scanner be a theorem prover with respect to how many bits survive an
> operation.
> For instance, I could easily add to your list, anding and oring
> operations which als
Hi,
On Fri, 11 May 2007, Rask Ingemann Lambertsen wrote:
>The first one is the insn pattern right below the mulsidi3 expander,
>right? Please give all insn patterns a name to make searches easier.
It's on the TODO list. :)
>May I ask why the original insn 7 isn't coded something lik
Hi,
On Thu, 10 May 2007, I wrote:
> I have a few problems with the m68k mulsidi3 pattern on the dataflow
> branch.
To illustrate the problem here is what happens during combine:
-(insn 7 28 8 2 ../gcc/gcc/testsuite/gcc.c-torture/execute/20001108-1.c:4
(parallel [
-(set (subreg:SI (
Hi,
I have a few problems with the m68k mulsidi3 pattern on the dataflow
branch.
Currently incorrect code is generated as the DF_REF_PARTIAL bit isn't
set for its destinations and dataflow thinks both set the register
completely, thus one destination is set to unused. I could change the
pattern to
Hi,
On Fri, 4 May 2007, Andrew Pinski wrote:
> On 5/4/07, Vincent Lefevre <[EMAIL PROTECTED]> wrote:
> > Perhaps it should be noted that these libraries are specific to x86
> > processors, since other processors don't have extended precision.
>
> m68k does too, just nobody uses it any more or th
Hi,
On Tue, 24 Apr 2007, Andreas Schwab wrote:
> > Even without this bug gcc usage of bitfield instruction has become a
> > little insane lately, e.g. 2.95/3.4 produce this code:
> >
> > retmeK:
> > link.w %a6,#0
> > move.l 8(%a6),%d0
> > unlk %a6
> > rts
>
> FWI
Hi,
On Tue, 24 Apr 2007, I wrote:
> simply copying values like this it's overkill, what makes this worse is
> that the rtl optimizers can often do as much with this (and in combination
^ not
> with subreg it's not getting better...)
This should make more sens
Hi,
Something broke the bitfield handling recently and before I delve deeper
into it, I'm hoping someone admits guilt. :)
This is taken from execute/20040709-1.c:
struct K { unsigned int k : 6, l : 1, j : 10, i : 15; };
struct K retmeK (struct K x)
{
return x;
}
This produces the following c
On Tue, 6 Mar 2007, Roman Zippel wrote:
> Reload has now to match (reg %d0) and (reg 38) above in insn 32 and after
> pseudo register replacement it looks like this:
>
> (insn 32 10 30 2 (parallel [
> (set (strict_low_part (reg:SI 1 %d1 [
Hi,
On Tue, 6 Mar 2007, Joern Rennecke wrote:
> In http://gcc.gnu.org/ml/gcc/2007-03/msg00128.html, you wrote:
> > One case is about multiple increments, the tree optimizer merges them and
> > increments the register only once, so if one only looks at the size of the
> > pointer value one misses
Hi,
On Mon, 5 Mar 2007, Roman Zippel wrote:
> > Yes, it is in general better now to split double-word length
> > operations before reload. It's not necessarily better to split as
> > early as possible, as that will essentially disable the RTL level loop
> > optim
Hi,
On Mon, 5 Mar 2007, Ian Lance Taylor wrote:
> > whereas with -fno-split-wide-types it generates this:
> >
> > move.l 16(%sp),%d0
> > move.l 20(%sp),%d1
> > move.l 8(%sp),%d2
> > add.l 12(%sp),%d1
> > addx.l %d2,%d0
> >
> > How can I get rid of these e
Hi,
The new subreg lowering pass seems to generate a bit worse code on m68k
than before, let's take simple example:
unsigned long long f(unsigned long long a, unsigned long long b)
{
return a + b;
}
where currently gcc generates code like this:
move.l 16(%sp),%d1
move.l
Hi,
I'mm currently looking at the dataflow branch for m68k mainly because of
the new auto-inc-dec pass, I worked a bit on the old code in flow.c, but
considering the new pass, I think it doesn't make much sense to continue
it.
I'm attaching my current patch and some test cases, but before delv
Hi,
I currently have a problem of how to best preserve a register note across
an instruction split, e.g. I had to change a define_split like this (from
m68k.md):
(define_split
[(set (match_operand 0 "register_operand" "")
(zero_extend (match_operand 1 "nonimmediate_src_operand" ""))
Hi,
I have a problem with 4.1 on m68k-linux, which miscompiles the following
test case during the gcse pass:
struct b {
unsigned a : 1;
unsigned b : 1;
unsigned c : 1;
unsigned d : 1;
};
unsigned int x = 1;
void f(int y, struct b *p)
{
switch (y)
Hi,
gcc 4.1 changed the typeof behaviour and now includes the type const
qualifier, which unfortunately breaks existing code. The example below is
simplified example from the Linux kernel (i386 was "fixed", but that's
not the only arch).
The first get_user() produces nice code with 4.0 and ear
40 matches
Mail list logo
