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]

[PATCH] PR18002: Undo fold_single_bit_test in do_jump


> Roger Sayle wrote:
> The issue concerns the code generated for expressions such as
> "if (x & C)" where C is a power-of-two.  The trickiness with
> trees such as "(x & C) != 0" is that the code we generate for
> them depends upon the context in which its used.  For control
> flow instructions its better to use a bitwise-AND of the constant
> C, however if the tree's value is assigned to a variable its
> best to implement this as "var = (x >> C') & 1" which doesn't
> require any conditional jumps, and is therefore preferable to
> "var = (x & C) ? 1 : 0".

Isn't the case of "var = (x & C) ? 1 : 0" a bit of an anomaly, as
would guess that in most conditional assignments of values would
not correspond to the simple case of 0 or 1 ? i.e.:

var = (x & C) ? some-likely-non-zero-value : some-likely-non-one-value

Therefore realistically the likely most likely common case is that
conditional jumps are unavoidable, but understand that >> may be more
potentially favorable on architecture targets which are capable of
multi-bit shifts if one of the operands may be reduced in magnitude,
but likely not otherwise as shifts can be expensive, (apparently even
on Pentium's as they have relatively large latencies?)?

So in general, it would seem that transforming a simple single-bit-&
operation into a multi-bit >> plus a single bit-& operation would seem
most frequently counterproductive, unless reverted prior to code-generation,
which seems a little odd; so wonder if the initial conversion should have
ever been done initially?



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