Roman Zippel <[EMAIL PROTECTED]> writes:
> The new subreg lowering pass seems to generate a bit worse code on m68k
> than before, let's take simple example:
FWIW
I see the opposite on i386: I have a function that strangely ran
slower with -fomit-frame-pointer than without on 4.1. With a 4.3
s
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 [orig:38+4 ] [38]))
> (mult:S
only the
umulsidi3 pattern are relevant for this) and I think found a bug somwhere,
although I'm not sure whether the subreg pass causes it or only trigggers
it (it goes away with -fno-split-wide-types).
I removed the '%' from the constraint to test proper reloads (which may
On Mon, Mar 05, 2007 at 02:29:05PM +0100, Roman Zippel wrote:
> challenges, as m68k is still a cc0 target and with instructions like
> addx.l above, so far I avoided splitting these at all.
It would be possible to add an X register to model that one
bit from the flags, since X is generally preser
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
Roman Zippel <[EMAIL PROTECTED]> writes:
> 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
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
