[LLVMdev] ICmp documentation clarification

Reid Spencer rspencer at reidspencer.com
Fri Jan 5 13:38:09 PST 2007


Hi Baptiste,

On Fri, 2007-01-05 at 22:10 +0100, Baptiste Lepilleur wrote:
> Reid Spencer wrote:
> > Hi Baptiste,
> >
> > On Fri, 2007-01-05 at 09:44 +0100, Baptiste Lepilleur wrote:
> >> I just want to make sure I understand the semantic of the icmp
> >> function correctly as assumption are dangerous in this domain.
> >>
> >> The syntax is specified as follow:
> >> <result> = icmp <cond> <ty> <var1>, <var2>   ; yields {bool}:result
> >>
> >> But I can not find the documentation for <ty>.
> >
> > <ty> is any of the integer types or a pointer type. It cannot be any
> > other type. The type of var1 and var2 must be identical and must be
> > <ty>
> 
> Thanks this clear things up.

You're welcome.

> 
> What is the rational behind the existance of both icmp and fcmp as the i/f 
> prefix seems to be redundant with <ty> ? 

The predicates are very different for the two instructions. See the
LangRef.html. Floating point comparisons can be ordered or unordered
which involves testing for NAN. The concept doesn't exist for integer
comparisons. Hence, there are two instructions to separate these sets of
predicates.

> Is it for performance purpose when 
> analysing the code ?

That's another reason, but not the main one. Optimizations only work
with either floating point or integer arithmetic so it is useful to have
two classes to distinguish the cases for example, code like:

if (ICmpInst *ICI = dyn_cast<ICmpInst>(I)) {
  .. integer optimizations ...
} else if (FCmpInst *FCI = dyn_cast<FCmpInst>(I)) {
  .. floating point optimizations ...
}

This idiom is used throughout LLVM. Since we treat them separately in
the code, it is best to match that with separate instructions at the
assembly level as well. 

> 
> >> [...]
> > Yes. When you truncate to bool, it really truncates so only the least
> > significant bit is retained.
> >
> >> %Y = trunc i32 122 to bool               ; yields bool:false
> 
> Maybe this example should be added to the doc to clarify this point.

Done.

> 
> Thanks,
> Baptiste. 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list