On Mon, May 04, 2015 at 12:33:38PM -0700, Richard Henderson wrote:
(1) Each target defines a set of constraint strings,
(2) A new target hook post-processes the asm_insn, looking for the
new constraint strings. The hook expands the condition prescribed
by the string, adjusting the
On Tue, May 5, 2015 at 6:50 AM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
Since it is pre-processed, there is no real reason to overlap this with
the constraints namespace; we could have e.g. =@[xy] (and @[xy] for
inputs) mean the target needs to do some xy transform here.
In fact,
On Tue, May 05, 2015 at 08:37:01AM -0700, Linus Torvalds wrote:
On Tue, May 5, 2015 at 6:50 AM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
Since it is pre-processed, there is no real reason to overlap this with
the constraints namespace; we could have e.g. =@[xy] (and @[xy] for
On Mon, May 04, 2015 at 12:33:38PM -0700, Richard Henderson wrote:
[snipped]
(3) Note that ppc is both easier and more complicated.
There we have 8 4-bit registers, although most of the integer
non-comparisons only write to CR0. And the vector non-comparisons
only write to CR1, though
On 05/02/2015 05:39 AM, Peter Zijlstra wrote:
static inline bool __test_and_clear_bit(long nr, volatile unsigned long *addr)
{
bool oldbit;
asm volatile (btr %2, %1
: CF (oldbit), +m (*addr)
: Ir (nr));
return oldbit;
}
Be
On 05/04/2015 01:35 PM, Linus Torvalds wrote:
On Mon, May 4, 2015 at 1:14 PM, H. Peter Anvin h...@zytor.com wrote:
I would argue that for x86 what you actually want is to model the
*conditions* that are available on the flags, not the flags themselves.
Yes. Otherwise it would be a nightmare
On 05/04/2015 12:33 PM, Richard Henderson wrote:
(0) The C level output variable should be an integral type, from bool on up.
The flags are a scarse resource, easily clobbered. We cannot allow user code
to keep data in the flags. While x86 does have lahf/sahf, they don't exactly
perform
On Mon, May 4, 2015 at 1:14 PM, H. Peter Anvin h...@zytor.com wrote:
I would argue that for x86 what you actually want is to model the
*conditions* that are available on the flags, not the flags themselves.
Yes. Otherwise it would be a nightmare to try to describe simple
conditions like le,
On 05/04/2015 01:14 PM, H. Peter Anvin wrote:
On 05/04/2015 12:33 PM, Richard Henderson wrote:
(0) The C level output variable should be an integral type, from bool on up.
The flags are a scarse resource, easily clobbered. We cannot allow user code
to keep data in the flags. While x86 does
On Mon, May 4, 2015 at 1:33 PM, Richard Henderson r...@redhat.com wrote:
A fair point. Though honestly, I was hoping that this feature would mostly be
used for conditions that are weird -- that is, not normally describable by
arithmetic at all. Otherwise, why are you using inline asm for it?
On 05/04/2015 01:45 PM, Linus Torvalds wrote:
On Mon, May 4, 2015 at 1:33 PM, Richard Henderson r...@redhat.com wrote:
A fair point. Though honestly, I was hoping that this feature would mostly
be
used for conditions that are weird -- that is, not normally describable by
arithmetic at all.
On 05/04/2015 01:57 PM, Richard Henderson wrote:
Sure.
I'd be more inclined to support these compound conditionals directly, rather
than try to get the compiler to recognize them after the fact.
Indeed, I believe we have a near complete set of them in the x86 backend
already. It'd just
12 matches
Mail list logo
