This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: inline asm constraints for conditions


Jamie Lokier <jamie@shareable.org> wrote:
> > On Mon, Sep 29, 2003 at 06:21:34PM +0100, Jamie Lokier wrote:
> > > If the flags register is killed, then "reloading" should be a simple
> > > matter of either redoing the comparison, as effectively happens all
> > > the time now, or saving the _particular_ comparison results that are
> > > wanted using setcc, sbbl etc. into an ordinary register.
> > 
> > In the case under discussion the compiler would not have access to the
> > instruction that set the flags -- it's hidden in an asm.  If the insns
> > in question were exposed via __builtins, the flags might have been set
> > by an instruction like xaddl or cmpxchg which cannot be re-done.

I don't think you can expect to recreate the condition - as was mentioned, the
compiler can't predict which bit(s) of the ASM statement were responsible, nor
can it predict what the side-effects of redoing would be.

> Later in that mail I described what to do when the instruction cannot
> be re-done, or when it's better not to redo it:
> 
> 	4. reload "moves" one condition register _to_ a general register
> 	   or memory using setcc/sbb.
> 
> 	5. reload "moves" one condition register _from_ a general
> 	   register or memory by doing a comparison against the saved
> 	   value to set the real flags again.

That's the sort of thing I was envisioning. The fallback is basically what
these constructs tend to do at the moment - use SETcc/SBB/CMOVcc (or their
equivalents) to store a "boolean" value in a variable, and then compare it
against something appropriate in an if statement later.

In the uttermost end, you could resort to conditional jumps to store the
value:

	<-- got condition in EFLAGS c/nc -->
		mov	$0,%eax
		jnc	0f
		mov	$1,%eax
	0:

> 	   Of course this clobbers all the other condition registers :)

Either the number of returning conditions could be limited to just one, or you
could use SETcc/CMOVcc multiple times.

> In other words, a particular condition is saved as a 0 or 1 value,
> using setcc/sbb.  The originating asm instruction is not redone.

Or, at least, zero or non-zero. Then you don't have to do SETcc+AND.

> > So, no, this would not help at all.
> 
> Perhaps it wouldn't, but I think the particular reason you gave is not
> the right one :)

But if you added this sort of constraint, you'd have to have the ability to
turning such an asm statement result into a real value anyway, and so you
could just build on that:

	int x;
	asm ("lock; bts %0,%1" : "=?c/nc"(x) : "rI"(nr), "m"(addr))
	printk("Bit was %d\n", x);

What you really want, of course, is:

	bool x;
	asm ("lock; bts %0,%1" : "=?c/nc"(x) : "rI"(nr), "m"(addr))
	printk("Bit was %d\n", x);

David


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]