Re: Couldn't `function(arg[static 3])` imply nonnull and array size in C?
On 04/05/15 07:40, Martin Uecker wrote: BTW: Why is 'nonnull' a function attribute and not something which can be attached to pointer types? I think this is something wanted for a long time: https://gcc.gnu.org/ml/gcc/2006-04/msg00550.html but nobody has implemented it yet. Perhaps there was some technical hurdle in the past, probably long gone. Clang has implemented this variation already sometime ago: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140203/098497.html so there is a precedent. Cheers, Manuel.
[RFC] Design for flag bit outputs from asms
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 the far better solution for this? Bug 59615 comment 7 states that
> they actually modeled the flags in the .md file, so the above should be
> possible to implement.
>
> Now GCC can decide to use "sbb %0, %0" to convert CF into a register
> value or use "jnc" / "jc" for branches, depending on what
> __test_and_clear_bit() was used for.
>
> We don't have to (ab)use asm goto for these things anymore; furthermore
> I think the above will naturally work with our __builtin_expect() hints,
> whereas the asm goto stuff has a hard time with that (afaik).
>
> That's not to say output operants for asm goto would not still be useful
> for other things (like your EXTABLE example).
>
(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 well. And other targets like arm don't even have that bad option.
Therefore, the language level semantics are that the output is a boolean store
into the variable with a condition specified by a magic constraint.
That said, just like the compiler should be able to optimize
void bar(int y)
{
int x = (y <= 0);
if (x) foo();
}
such that we only use a single compare against y, the expectation is that
within a similarly constrained context the compiler will not require two tests
for these boolean outputs.
Therefore:
(1) Each target defines a set of constraint strings,
E.g. for x86, wherein we're almost out of constraint letters,
ja aux carry flag
jc carry flag
jo overflow flag
jp parity flag
js sign flag
jz zero flag
E.g. for arm/aarch64 (using "j" here, but other possibilities exist):
jn negative flag
jc carry flag
jz zero flag
jv overflow flag
E.g. for s390x (I've thought less about what's useful here)
j where m is a hex digit, and is the mask of CC values
for which the condition is true; exactly corresponding
to the M1 field in the branch on condition instruction.
(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 asm_insn as required.
E.g.
bool x, y, z;
asm ("xyzzy" : "=jc"(x), "=jp"(y), "=jo"(z) : : );
originally
(parallel [
(set (reg:QI 83 [ x ])
(asm_operands/v:QI ("xyzzy") ("=jc") 0 []
[]
[] z.c:4))
(set (reg:QI 84 [ y ])
(asm_operands/v:QI ("xyzzy") ("=jp") 1 []
[]
[] z.c:4))
(set (reg:QI 85 [ z ])
(asm_operands/v:QI ("xyzzy") ("=jo") 2 []
[]
[] z.c:4))
(clobber (reg:QI 18 fpsr))
(clobber (reg:QI 17 flags))
])
becomes
(parallel [
(set (reg:CC 17 flags)
(asm_operands/v:CC ("xyzzy") ("=j_") 0 []
[]
[] z.c:4))
(clobber (reg:QI 18 fpsr))
])
(set (reg:QI 83 [ x ])
(ne:QI (reg:CCC 17 flags) (const_int 0)))
(set (reg:QI 84 [ y ])
(ne:QI (reg:CCP 17 flags) (const_int 0)))
(set (reg:QI 85 [ z ])
(ne:QI (reg:CCO 17 flags) (const_int 0)))
which ought to assemble to something like
xyzzy
setc %dl
setp %cl
seto %r15l
Note that rtl level data flow is preserved via the flags hard register,
and the lifetime of flags would not extended any further than we would
for a normal cstore pattern.
Note that the output constraints are adjusted to a single internal "=j_"
which would match the flags register in any mode. We can collapse
several output flags to a single set of the flags hard register.
(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 of course that's of less interest in the
context of kernel code.
For the purposes of cr0, the same scheme could certainly work, although
the hook would not insert a hard register use, but rather a pseudo to
be allocated to cr0 (constaint "x").
That said, it's my understanding that "dot insns", setting cr0 are
expensive in current processor generations. There's also a lot less
of the x86-style "operate and set a flag based on something useful".
Can anyone think of any drawbacks
Re: [RFC] Design for flag bit outputs from asms
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 well. And other targets like arm don't even have that bad option.
>
> Therefore, the language level semantics are that the output is a boolean store
> into the variable with a condition specified by a magic constraint.
>
> That said, just like the compiler should be able to optimize
>
> void bar(int y)
> {
> int x = (y <= 0);
> if (x) foo();
> }
>
> such that we only use a single compare against y, the expectation is that
> within a similarly constrained context the compiler will not require two tests
> for these boolean outputs.
>
> Therefore:
>
> (1) Each target defines a set of constraint strings,
>
>E.g. for x86, wherein we're almost out of constraint letters,
>
> ja aux carry flag
> jc carry flag
> jo overflow flag
> jp parity flag
> js sign flag
> jz zero flag
>
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.
There are 16 such conditions, 8 if we discard the inversions.
It is notable that the auxiliary carry flag has no Jcc/SETcc/CMOVcc
instructions; it is only ever consumed by the DAA/DAS instructions which
makes it pointless to try to model it in a compiler any more than, say, IF.
> (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 asm_insn as required.
>
> E.g.
>
> bool x, y, z;
> asm ("xyzzy" : "=jc"(x), "=jp"(y), "=jo"(z) : : );
Other than that, this is exactly what would be wonderful to see.
-hpa
Re: [RFC] Design for flag bit outputs from asms
On 05/04/2015 01:14 PM, H. Peter Anvin wrote:
>>
>> Therefore:
>>
>> (1) Each target defines a set of constraint strings,
>>
>>E.g. for x86, wherein we're almost out of constraint letters,
>>
>> ja aux carry flag
>> jc carry flag
>> jo overflow flag
>> jp parity flag
>> js sign flag
>> jz zero flag
>>
>
> 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.
> There are 16 such conditions, 8 if we discard the inversions.
>
> It is notable that the auxiliary carry flag has no Jcc/SETcc/CMOVcc
> instructions; it is only ever consumed by the DAA/DAS instructions which
> makes it pointless to try to model it in a compiler any more than, say, IF.
>
OK, let me qualify that. This is only necessary if it is impractical
for gcc to optimize boolean combinations of flags. If such
optimizations are available then it doesn't matter and is probably
needlessly complex. For example:
char foo(void)
{
bool zf, sf, of;
asm("xyzzy" : "=jz" (zf), "=js" (sf), "=jo" (of));
return zf || (sf != of);
}
... should compile to ...
xyzzy
setng %al
ret
-hpa
Re: [RFC] Design for flag bit outputs from asms
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 have lahf/sahf, they don't exactly
>> perform well. And other targets like arm don't even have that bad option.
>>
>> Therefore, the language level semantics are that the output is a boolean
>> store
>> into the variable with a condition specified by a magic constraint.
>>
>> That said, just like the compiler should be able to optimize
>>
>> void bar(int y)
>> {
>> int x = (y <= 0);
>> if (x) foo();
>> }
>>
>> such that we only use a single compare against y, the expectation is that
>> within a similarly constrained context the compiler will not require two
>> tests
>> for these boolean outputs.
>>
>> Therefore:
>>
>> (1) Each target defines a set of constraint strings,
>>
>>E.g. for x86, wherein we're almost out of constraint letters,
>>
>> ja aux carry flag
>> jc carry flag
>> jo overflow flag
>> jp parity flag
>> js sign flag
>> jz zero flag
>>
>
> 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.
> There are 16 such conditions, 8 if we discard the inversions.
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?
> It is notable that the auxiliary carry flag has no Jcc/SETcc/CMOVcc
> instructions; it is only ever consumed by the DAA/DAS instructions which
> makes it pointless to try to model it in a compiler any more than, say, IF.
Oh yeah. Consider that dropped.
r~
Re: [RFC] Design for flag bit outputs from asms
On Mon, May 4, 2015 at 1:14 PM, H. Peter Anvin 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", which a rather complicated combination of three of the actual flag bits: ((SF ^^ OF) || ZF) = 1 which would just be ridiculously painful for (a) the user to describe and (b) fior the compiler to recognize once described. Now, I do admit that most of the cases where you'd use inline asm with condition codes would probably fall into just simple "test ZF or CF". But I could certainly imagine other cases. Linus
Re: [RFC] Design for flag bit outputs from asms
On 05/04/2015 01:35 PM, Linus Torvalds wrote: > On Mon, May 4, 2015 at 1:14 PM, H. Peter Anvin 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", which a rather complicated combination of three > of the actual flag bits: > > ((SF ^^ OF) || ZF) = 1 > > which would just be ridiculously painful for (a) the user to describe > and (b) fior the compiler to recognize once described. > > Now, I do admit that most of the cases where you'd use inline asm with > condition codes would probably fall into just simple "test ZF or CF". > But I could certainly imagine other cases. > Yes, although once again I'm more than happy to let gcc do the boolean optimizations if it already has logic to do so (which it might have/want for its own reasons.) -hpa
Re: [RFC] Design for flag bit outputs from asms
On Mon, May 4, 2015 at 1:33 PM, Richard Henderson 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? I could easily imagine using some of the combinations for atomic operations. For example, doing a "lock decl", and wanting to see if the result is negative or zero. Sure, it would be possible to set *two* booleans (ZF and SF), but there's a contiional for "BE".. Linus
Re: [RFC] Design for flag bit outputs from asms
On 05/04/2015 01:45 PM, Linus Torvalds wrote: > On Mon, May 4, 2015 at 1:33 PM, Richard Henderson 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? > > I could easily imagine using some of the combinations for atomic operations. > > For example, doing a "lock decl", and wanting to see if the result is > negative or zero. Sure, it would be possible to set *two* booleans (ZF > and SF), but there's a contiional for "BE".. 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 be a matter of selecting the spellings for the constraints. r~
Re: [RFC] Design for flag bit outputs from asms
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 be a matter of selecting the spellings for the > constraints. > Whichever works for you. The full set of conditions, mnemonics, and a bitmask with the bits in the order from MSB to LSB (OF,SF,ZF,PF,CF) which is probably the sanest way to model these for the purpose of boolean optimization. Opcode Mnemonics Condition Bitmask 0 o OF 0x 1 no !OF 0x 2 b/c/nae CF 0x 3 ae/nb/nc!CF 0x 4 e/z ZF 0xf0f0f0f0 5 ne/nz !ZF 0x0f0f0f0f 6 na CF || ZF0xfafafafa 7 a !CF && !ZF 0x05050505 8 s SF 0xff00ff00 9 ns !SF 0x00ff00ff A p/pePF 0x B np/po !PF 0x C l/nge SF != OF0x0000 D ge/nl SF == OF0xffff E le/ng ZF || (SF != OF)0xf0f0 F g/nle !ZF && (SF == OF) 0x0f0f -hpa
Re: Compiler warnings while compiling gcc with clang
On Mon, May 4, 2015 at 9:42 PM, Aditya K wrote: > I was able to successfully bootstrap gcc by using clang as the stage 1 > compiler. I configured gcc using the following arguments. > > ../configure --disable-multilib --enable-bootstrap --enable-languages=c,c++ > CC=/work/llvm/install-release/bin/clang > CXX=/work/llvm/install-release/bin/clang++ > > And the bootstrap was successful. One useful thing I got to see was clang > warnings. Clang produced several warnings (> 1000 unique ones). I have > attached two files with this email. > 1. sorted list of warnings (summary only) > 2. complete build log. > > I want to know that is there any interest in resolving these warnings? I went > through the list a little bit and some warnings > appear to be quite useful. e.g. > > 1. warning: struct 'varpool_node' was previously declared as a class > [-Wmismatched-tags] > > 2. ../../gcc/cgraph.h../../gcc/wide-int.h::18881125::101:: warningwarning: : > class 'cgraph_node' was previously declared as a struct [-Wmismatch > ed-tags]'fixed_wide_int_storage' defined as a class template here but > previously declared as a struct template [-Wmismatched-tags] These two are bogus and really clang in GCC's mind. The main reason is the standard says struct and class are the same thing. We are not going to fix these kind of issues in GCC sources since they don't really help. Thanks, Andrew
