This is the mail archive of the
mailing list for the GCC project.
Re: Conditional negation elimination in tree-ssa-phiopt.c
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Kyrill Tkachov <kyrylo dot tkachov at arm dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 12 Aug 2014 11:39:07 +0200
- Subject: Re: Conditional negation elimination in tree-ssa-phiopt.c
- Authentication-results: sourceware.org; auth=none
- References: <53E8C81B dot 1070303 at arm dot com> <53E91FD8 dot 2000005 at redhat dot com>
On Mon, Aug 11, 2014 at 9:56 PM, Jeff Law <firstname.lastname@example.org> 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
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
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
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?
>> 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.