llvm dev - Jan 2007 - [LLVMdev] ICmp documentation clarification

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.

What is the rational behind the existance of both icmp and fcmp as the i/f 
prefix seems to be redundant with <ty> ? Is it for performance purpose
when
analysing the code ?
>> [...]
> 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.

Thanks,
Baptiste.

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

Hi all,

What does LLVM assume when optimising volatiles? I'm finding difficulty 
generating multithreaded code that makes sense because the compiler 
seems to be assuming single-threaded semantics. Is there any special 
flags I should be using in order to safely generate multithreaded code?

 From my experiments, it very much appears that the generated code has 
been optimised in such a way that threading semantics is broken, and 
that volatile is not taken into account. Is this true? Is there a fix?

(This is a major showstopper, so any help would be greatly appreciated)

Thanks,
Sarah Thompson