[LLVMdev] Invalid comparison instruction generation

[Eli Friedman]

On Mon, Nov 10, 2008 at 5:00 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote:
> Eli,
> Using the variables from the original IR,
> assuming tmp == tmp1 and assume the value is not nan
> ogt(tmp, tmp1) is !isnan(tmp) && !isnan(tmp1) && tmp > tmp1, or false
> ule(tmp, tmp1) is isnan(tmp) || isnan(tmp1) || tmp <= tmp1, or true

Correct; in fact, ogt and ule are exact opposites.

> So, this is invalid, or am I misunderstanding what ogt and ule stand
> for?

What you're missing is the xor in the pre-combine graph; I assume it
got added during branch lowering.

> Assuming this is valid, why convert comparison instructions instead of
> just passing them through as they originally exist? The backend I am
> targeting does not support all comparison instructions and trying to
> guess which instruction LLVM converted the current comparison
> instruction from and then converting to a supported instruction is not
> as simple as it can be.

It's not a matter of guessing... you need to able to support all of
the possible comparisons, since they can be introduced by optimizers
at multiple levels.

> For example, I need to convert all ogt instructions to an olt
> instruction with LHS and RHS swapped, but since ogt is converted to ule,
> do I convert all ule into olt and swap?

The existing legalization infrastructure for condition codes is in
SelectionDAGLegalize::LegalizeSetCCCondCode.  If this isn't flexible
enough, you might need to modify it a bit. You should be able to just
do something like "setCondCodeAction(ISD::SETOGT, MVT::f64, Expand);"
for the unsupported comparisons, and let Legalize should take care of
the rest.

Oh, and it looks like there's a legitimate bug in
DAGCombiner::visitXOR: it needs to check whether condition codes are
legal before transforming them.

-Eli