Re: [RFC 0/6] Flags outputs for asms

2015-05-11 Thread Segher Boessenkool
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 .

Re: [RFC 0/6] Flags outputs for asms

2015-05-08 Thread Richard Henderson
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,

Re: [RFC 0/6] Flags outputs for asms

2015-05-08 Thread Segher Boessenkool
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 consi

Re: [RFC 0/6] Flags outputs for asms

2015-05-08 Thread Richard Henderson
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.

Re: [RFC 0/6] Flags outputs for asms

2015-05-08 Thread Jeff Law
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 i

Re: [RFC 0/6] Flags outputs for asms

2015-05-08 Thread Segher Boessenkool
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

Re: [RFC 0/6] Flags outputs for asms

2015-05-08 Thread Richard Henderson
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 allocat

Re: [RFC 0/6] Flags outputs for asms

2015-05-08 Thread H. Peter Anvin
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 > excellen

Re: [RFC 0/6] Flags outputs for asms

2015-05-08 Thread Richard Henderson
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) > {

Re: [RFC 0/6] Flags outputs for asms

2015-05-08 Thread Jeff Law
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)

Re: [RFC 0/6] Flags outputs for asms

2015-05-08 Thread Jay Foad
On 8 May 2015 at 16:23, Richard Henderson wrote: > Yes, the i386 backend has not implemented conditional sibcalls. See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60159 Jay.

Re: [RFC 0/6] Flags outputs for asms

2015-05-08 Thread Richard Henderson
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

Re: [RFC 0/6] Flags outputs for asms

2015-05-07 Thread H. Peter Anvin
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?

Re: [RFC 0/6] Flags outputs for asms

2015-05-07 Thread H. Peter Anvin
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

[RFC 0/6] Flags outputs for asms

2015-05-07 Thread Richard Henderson
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 c