bug 20542

[Norman Rink]

Hi Tim,

My apologies, I made the mistake of not explaining myself properly.

I think in the case of a SETCC node you are absolutely right, and this is the case that the comment in the source code describes. The same code, however, is also invoked on a SELECT_CC node, and this is what I had in mind:

%selcc = (x cc y) ? N0.op(2) : N0.Op(3)
%xor = xor %selcc, 1

For this sequence the DACCombiner will return 

%xor = (x !cc y) ? N0.op(2) : N0.Op(3),

And this is what I was targeting with the patch.

Best,

Norman

-----Original Message-----
From: Tim Northover [mailto:t.p.northover at gmail.com] 
Sent: 18 August 2014 15:19
To: Norman Rink
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: bug 20542

Hi Norman,

On 18 August 2014 15:05, Norman Rink <nrink at broadcom.com> wrote:
> "xor (x cc y), 1" --> "(x !cc y)".
>
> In other words, the "xor ?, 1" is treated like a "not" operation, which is blatantly wrong if the argument is wider than one bit. I might be missing something too though.

But the "(x cc y)" isn't a generic operation. Assuming your target has
TLI.getBooleanContents() == ZeroOrOneBooleanContent (the other cases
are analogous[1]) its value can only be 0 or 1. In that case xor with
1 *is* "not".

Cheers.

Tim.

[1] If it's ZeroOrNegativeOne then "(x cc y)" can (unsurprisingly)
only be 0 or -1, so you need to check for "xor (x cc y), -1" to act as
a not. If it's Undefined than the high bits are meaningless and you
should be able to accept "xor (x cc y), C" where C is any constant
with the low bit set.