This is the mail archive of the gcc-patches@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: [PATCH] Teach VRP about __builtin_{ffs,parity,popcount,clz,ctz,clrsb}{,l,ll,imax} (PR target/29776)


On Tue, 9 Jul 2013, Richard Earnshaw wrote:

> On ARM, CLZ has a defined result at zero (32).  Furthermore, the ACLE
> specification defines (in the header arm_acle.h)  __clz(n) as an intrinsic
> aimed at the CLZ instruction; __clz() has a defined result at 0.  We want to
> use __builtin_clz as the implementation for __clz rather than inventing
> another one; but that would require the compiler to handle zero correctly.

Assuming the header will come with GCC, it can assume semantics we don't 
document for user code - such as that __builtin_clz is defined at 0, if 
that is the case with a given GCC version and target architecture.  If the 
semantics change, the header can then be changed at the same time.

(I'd still encourage user code wanting a defined value at 0 to do e.g.

static inline int clz (int n) { return n == 0 ? 32 : __builtin_clz (n); }

and hope GCC will optimize away the test for 0 when the instruction 
semantics make it unnecessary - if it doesn't, it should be fixed to do 
so.  And it's certainly fine to put such code in an intrinsic header if 
useful.)

-- 
Joseph S. Myers
joseph@codesourcery.com


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