Hi! On Fri, Jan 10, 2020 at 10:35:04PM +0100, Jakub Jelinek wrote: > On Thu, Jan 09, 2020 at 02:26:10PM +0100, Richard Biener wrote: > > > >> + tree lhs = gimple_assign_lhs (stmt); > > > >> + bool zero_ok = CTZ_DEFINED_VALUE_AT_ZERO (TYPE_MODE (type), > > > >> val); > > > > > > > > since we're using the optab entry shouldn't you check for == 2 here? > > > > > > Yes, that looks more correct (it's not clear what 1 means exactly). > > 1 is what e.g. x86 uses with -mbmi, and I think it is what most targets > actually define if they have any defined value there, exception is > aarch64/arm, powerpc, gcn, nvptx and mips.
1 vs. 2 only makes a difference when expanding ffs, it seems. > Given: > int foo (int x) { return __builtin_ctz (x); } > int bar (int x) { return x ? __builtin_ctz (x) : 32; } > on x86 -mbmi we with CTZ_DEFINED_VALUE_AT_ZERO being 1 and value type_size > emit the same code, we'd need to find out if that is something done for all > targets or just a few, It doesn't do that for rs6000 (not for clz either, which is easier for us, the expansion of ctz depends on multiple factors). (Note that "foo" has UB whenever x == 0, btw. -- it would be nice if something like "bar" would generate the optimal code as well. Is there some other code that will just work?) > and if for all that have CTZ_DEFINED_VALUE_AT_ZERO 1, > we could perhaps just emit branchy code and wait for RTL to fix that up. Where would RTL fix that? In what pass, I mean. Segher