[Bug target/29776] result of ffs/clz/ctz/popcount/parity are already sign-extended

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Unfortunately looking at longlong.h, the header on some targets uses
__builtin_clz* or __builtin_ctz* even with defining COUNT_LEADING_ZEROS_0 to
some value (e.g. on alpha, arm, avr, coldfire, mips).
libgcc itself doesn't use COUNT_LEADING_ZEROS_0 macro, nor does glibc, but
wonder if other projects don't use it.
Code that happened to work (albeit, according to gcc documentation (but not
longlong.h) undefined) could break with my patch.
So, either we'd need to change longlong.h not to define COUNT_LEADING_ZEROS_0
when count_leading_zeros is implemented using the builtin, or we'd need to be
more conservative in the VRP patch.  The problem is what is more conservative.
The C?Z_DEFINED_VALUE_AT_ZERO macros aren't unfortunately immediately usable,
because they are well defined just for some integer modes (the ones for which
there is some hw insn or at least optab), while the builtin might be for some
other mode (larger or smaller).  If the builtin is for smaller mode and HW
supports only wider insns, generally clz is expanded as clz<larger> +
(<largerbitsize> - <thisbitsize>), ctz just as doing larger ctz and not
adjusting in any way.  So perhaps VRP could check whether there is an optab
for the mode of the builtin and if yes, look at its C.Z_DEFINED_VALUE_AT_ZERO,
otherwise assume undefined.  That would let the longlong.h work, supposedly
it uses the builtins only for the modes which are in hw (otherwise the libgcc
implementation using those macros would be not working).
Because trying to handle all the cases would be a mess, looking at
CLZ_DEFINED_VALUE_AT_ZERO when it is defined it is usually number of bits in
the mode and even the various extra clz expansions (both the widening which is
expanded as wider clz + difference of the wider and narrower mode bitsize and
doubleword narrowing which is expanded as runtime non-zero check on the first
word and either clz of the first word or bitsize difference + clz of second
word) probably honor it, but for ctz some targets use bitsize, some targets use
-1, but e.g. when widening we'd happily return bitsize of the larger mode and
not adjust, or when ctz is expanded using clz it can be again different.

So, thoughts on this?