llvm dev - Nov 2017 - Signed or unsigned EQ/NEQ

Hello,

In one of the loop transformations I am  developing, I need to convert eq
and neq loop latch condition into less than or greater than depending on
the control flow.



The problem is that  CmpInst::ICMP_EQ and CmpInst::ICMP_NE are neither
signed nor unsigned in LLVM. Also, I did not find a way to find out if the
integer operands of the CmpInst are signed or unsigned. Apparently, LLVM
does not distinguish in its type system between signed and unsigned
variables. So, I am not able to generate the appropriate signed or unsigned
ICMP_(S|U)LT or ICMP_(S|U)GT.


Do you have a solution for this?


Thanks,

Dounia
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171117/7f3a7312/attachment.html>

On 17 Nov 2017, at 21:11, Dounia Khaldi via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> The problem is that  CmpInst::ICMP_EQ and CmpInst::ICMP_NE are neither
signed nor unsigned in LLVM. Also, I did not find a way to find out if the
integer operands of the CmpInst are signed or unsigned. Apparently, LLVM does
not distinguish in its type system between signed and unsigned variables. So, I
am not able to generate the appropriate signed or unsigned ICMP_(S|U)LT or
ICMP_(S|U)GT.
In what way would you expect a signed and unsigned integer to differ in equality
comparison?  Two integers are equal if they have the same bit pattern, they are
not equal if they do not.  If you want help in constructing a signed and
unsigned notion of equality then you’ll first have to define what you want it to
mean, or you are unlikely to find anyone able to help.

David

Can you figure out the induction variable range?

If it is within [0, signed-max], then both signed and unsigned operations
produce the same result, no?


On Sat, Nov 18, 2017 at 12:22 PM, David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 17 Nov 2017, at 21:11, Dounia Khaldi via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > The problem is that  CmpInst::ICMP_EQ and CmpInst::ICMP_NE are neither
> signed nor unsigned in LLVM. Also, I did not find a way to find out if the
> integer operands of the CmpInst are signed or unsigned. Apparently, LLVM
> does not distinguish in its type system between signed and unsigned
> variables. So, I am not able to generate the appropriate signed or unsigned
> ICMP_(S|U)LT or ICMP_(S|U)GT.
>
> In what way would you expect a signed and unsigned integer to differ in
> equality comparison?  Two integers are equal if they have the same bit
> pattern, they are not equal if they do not.  If you want help in
> constructing a signed and unsigned notion of equality then you’ll first
> have to define what you want it to mean, or you are unlikely to find anyone
> able to help.
>
> David
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171118/9786162c/attachment.html>

Hi,

I am writing a decompiler. For this, i need to do type inference
propagation. EQ/NEQ do not provide any indication of type. So the only
solution is to infer it from other uses of the same registers.
I think you will have to do the same.
Also, there are problem edge cases. What if one register is signed and the
other is unsigned?

Kind regards

James

On 17 Nov 2017 21:12, "Dounia Khaldi via llvm-dev" <llvm-dev at
lists.llvm.org>
wrote:
> Hello,
>
> In one of the loop transformations I am  developing, I need to convert eq
> and neq loop latch condition into less than or greater than depending on
> the control flow.
>
>
>
> The problem is that  CmpInst::ICMP_EQ and CmpInst::ICMP_NE are neither
> signed nor unsigned in LLVM. Also, I did not find a way to find out if the
> integer operands of the CmpInst are signed or unsigned. Apparently, LLVM
> does not distinguish in its type system between signed and unsigned
> variables. So, I am not able to generate the appropriate signed or unsigned
> ICMP_(S|U)LT or ICMP_(S|U)GT.
>
>
> Do you have a solution for this?
>
>
> Thanks,
>
> Dounia
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171118/25998c82/attachment.html>

Thanks, James.
This answers my question. I will have to retrieve other operations that use
the same value. But even this won't work in all case.


On Sat, Nov 18, 2017 at 7:28 AM, James Courtier-Dutton <
james.dutton at gmail.com> wrote:
> Hi,
>
> I am writing a decompiler. For this, i need to do type inference
> propagation. EQ/NEQ do not provide any indication of type. So the only
> solution is to infer it from other uses of the same registers.
> I think you will have to do the same.
> Also, there are problem edge cases. What if one register is signed and the
> other is unsigned?
>
> Kind regards
>
> James
>
> On 17 Nov 2017 21:12, "Dounia Khaldi via llvm-dev" <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hello,
>>
>> In one of the loop transformations I am  developing, I need to convert
eq
>> and neq loop latch condition into less than or greater than depending
on
>> the control flow.
>>
>>
>>
>> The problem is that  CmpInst::ICMP_EQ and CmpInst::ICMP_NE are neither
>> signed nor unsigned in LLVM. Also, I did not find a way to find out if
the
>> integer operands of the CmpInst are signed or unsigned. Apparently,
LLVM
>> does not distinguish in its type system between signed and unsigned
>> variables. So, I am not able to generate the appropriate signed or
unsigned
>> ICMP_(S|U)LT or ICMP_(S|U)GT.
>>
>>
>> Do you have a solution for this?
>>
>>
>> Thanks,
>>
>> Dounia
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171120/b5052df2/attachment.html>