This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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