On Fri, May 08, 2015 at 01:15:25PM -0700, Richard Henderson wrote:
But it *does* try to match an intermediate pattern,
(set (reg:CCGC 17 flags)
(compare:CCGC (reg:CCGC 17 flags)
(const_int 0 [0])))
Patch posted at http://gcc.gnu.org/ml/gcc-patches/2015-05/msg00918.html.
Segher
On 8 May 2015 at 16:23, Richard Henderson r...@redhat.com wrote:
Yes, the i386 backend has not implemented conditional sibcalls.
See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60159
Jay.
On 05/07/2015 06:20 PM, H. Peter Anvin wrote:
This is a separate issue which really shouldn't have anything to do with
this, but is there a specific reason why:
void good1(int x, int y)
{
_Bool pf;
asm(cmpl %2,%1
: =@ccp (pf)
: r (x), g (y));
if (pf)
beta();
On 05/08/2015 09:23 AM, Richard Henderson wrote:
On 05/07/2015 06:20 PM, H. Peter Anvin wrote:
This is a separate issue which really shouldn't have anything to do with
this, but is there a specific reason why:
void good1(int x, int y)
{
_Bool pf;
asm(cmpl %2,%1
: =@ccp (pf)
On 05/08/2015 08:54 AM, Richard Henderson wrote:
Anyway, I'll look into whether the branch around alpha can be optimized, but
I'd be shocked if I'd be able to do anything about the branch around beta.
True, there's nothing in between that will clobber the flags so it would be an
excellent
On 05/07/2015 06:15 PM, H. Peter Anvin wrote:
/* This case really should produce good code in both cases */
void good1(int x, int y)
{
_Bool pf;
asm(cmpl %2,%1
: =@ccp (pf)
: r (x), g (y));
if (pf)
beta();
}
void bad1(int x, int y)
{
_Bool le, pf;
Hi Richard,
On Fri, May 08, 2015 at 01:15:25PM -0700, Richard Henderson wrote:
But it *does* try to match an intermediate pattern,
(set (reg:CCGC 17 flags)
(compare:CCGC (reg:CCGC 17 flags)
(const_int 0 [0])))
which can be considered a no-op move.
Maybe we should teach
On 05/08/2015 02:15 PM, Richard Henderson wrote:
But it *does* try to match an intermediate pattern,
(set (reg:CCGC 17 flags)
(compare:CCGC (reg:CCGC 17 flags)
(const_int 0 [0])))
which can be considered a no-op move. If I add the attached pattern, then the
combination happens
On 05/08/2015 02:32 PM, Jeff Law wrote:
On 05/08/2015 02:15 PM, Richard Henderson wrote:
But it *does* try to match an intermediate pattern,
(set (reg:CCGC 17 flags)
(compare:CCGC (reg:CCGC 17 flags)
(const_int 0 [0])))
which can be considered a no-op move. If I add the
On 05/08/2015 02:14 PM, Segher Boessenkool wrote:
Cleaner? In this code? Heh.
Heh.
use_crosses_set_p often estimates pessimistically. Is that what is
happening here? Using real dataflow in combine would fix that (and many
other problems). Not that that helps you right now ;-)
Yes, I
On Fri, May 08, 2015 at 03:32:58PM -0600, Jeff Law wrote:
On 05/08/2015 02:15 PM, Richard Henderson wrote:
But it *does* try to match an intermediate pattern,
(set (reg:CCGC 17 flags)
(compare:CCGC (reg:CCGC 17 flags)
(const_int 0 [0])))
which can be considered a no-op
On 05/08/2015 08:54 AM, Richard Henderson wrote:
I have a feeling I know why these didn't get merged.
The global optimizers aren't allowed to operate on hard registers lest they
extend the lifetime of the hard register such that it creates an impossible
situation for the register allocator.
Here's a prototype for i386 only, which stands up to light testing.
I'd rather post this tonight rather than wait until tomorrow when I
can write more proper dejagnu tests.
I've tested the intermedate patches via config-list.mk, so despite
mucking around with vec.h vs target.h, all targets still
On 05/07/2015 02:38 PM, Richard Henderson wrote:
Here's a prototype for i386 only, which stands up to light testing.
I'd rather post this tonight rather than wait until tomorrow when I
can write more proper dejagnu tests.
I've tested the intermedate patches via config-list.mk, so despite
This is a separate issue which really shouldn't have anything to do with
this, but is there a specific reason why:
void good1(int x, int y)
{
_Bool pf;
asm(cmpl %2,%1
: =@ccp (pf)
: r (x), g (y));
if (pf)
beta();
}
... ends up generating a jump to a jump?
15 matches
Mail list logo
