[PATCH] PR90838: Support ctz idioms

[Segher Boessenkool]

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