[llvm-dev] Signed or unsigned EQ/NEQ

James Courtier-Dutton via llvm-dev llvm-dev at lists.llvm.org
Fri Nov 24 00:30:40 PST 2017


True. In the absence of other type info, i assume unsigned.
It is the least risky. For example if you had assumed signed, and it turned
out to be a pointer, it could cause problems.

I am curious. In what situations is splitting and EQ into GE and LE etc.

Kind regards


On 20 Nov 2017 16:36, "Dounia Khaldi" <khaldi.dounia at gmail.com> wrote:

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/20171124/78cfe1eb/attachment.html>

More information about the llvm-dev mailing list