This is the mail archive of the gcc@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: Conditional negation elimination in tree-ssa-phiopt.c


On Mon, Aug 11, 2014 at 9:56 PM, Jeff Law <law@redhat.com> wrote:
> On 08/11/14 07:41, Kyrill Tkachov wrote:
>>
>>
>> I haven't been able to get combine to match the comparison+xor+neg+plus
>> RTL and it seems like it would be just a workaround to undo the
>> tree-level transformation.
>
> Yea, it'd just be a workaround, but it's probably the easiest way to deal
> with this problem.  Can you describe in further detail why you weren't able
> to get this to work?

Too many instructions to combine I guess.  You might want to add
intermediate "combine" insn-and-splits.  If that's still a no-go then
read on.

OTOH a suitable place to "undo" would be smarter RTL expansion
that detects this pattern (and hope for TER to still apply - thus
no CSE opportunities going in your way).  For your testcase TER
allows

r_5 replace with --> r_5 = (int) _4;

_8 replace with --> _8 = _4 != 0;

_10 replace with --> _10 = -_9;

_11 replace with --> _11 = _10 ^ r_5;

_12 replace with --> _12 = _11 + _9;

which unfortunately already "breaks" because of the multi-use _9
and _4.

Now - the way out here is a GIMPLE pass right before expansion
that performs pattern detection and generates target specific code suitable
for optimal expand.  Fortunately we already have that with
pass_optimize_widening_mul (which does widen-mul and fma detection).

This is the place where you'd deal with such pattern, generating
a suitable compound operation (or two, dependent on expansion
and insn pattern details).  This of course usually requires new
tree codes or internal functions.  For more arcane stuff like
your conditional negate I'd prefer an internal function.

Of course you then have to add an optab or a target hook to
do custom internal function expansion.  I suppose for internal
functions a target hook would be nicer than a generic optab?

Thanks,
Richard.



>
>>
>> What is the most acceptable way of disabling this transformation for a
>> target that has a conditional negation instruction?
>
> In general, we don't want target dependencies in the gimple/ssa optimizers.
>
> Jeff


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