ICmp documentation clarification

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>. Is the following interpretation correct:
Both <var1> and <var2> are converted to <ty> using the semantic of the trunc instruction before processing the comparison operation.

Concerning instruction trunc, is bool considered to be an alias to type i1. If so, does the following stand true:
%Y = trunc i32 123 to bool ; yields bool:true%Y = trunc i32 122 to bool ; yields bool:falseBaptiste.

Hi Baptiste,

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>

Is the following
interpretation correct:
Both <var1> and <var2> are converted to <ty> using the semantic of the trunc
instruction before processing the comparison operation.

No, <var1> and <var2> are not converted or modified by this instruction.
The values of the integers or pointers are compared, that's it.

Concerning instruction trunc, is bool considered to be an alias to type i1.

Yes.

If so, does the following stand true:
%Y = trunc i32 123 to bool ; yields bool:true

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:falseBaptiste.

Yes.

Reid Spencer wrote:

Hi Baptiste,

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,

Reid Spencer wrote:
> Hi Baptiste,
>
>> 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.

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?

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