[llvm-dev] Pointer comparison folding

Juneyoung Lee via llvm-dev llvm-dev at lists.llvm.org
Fri Apr 24 12:06:48 PDT 2020

If the address is known precisely, I think the icmp should be allowed to be
The equivalent assembly will always say true, so there is no reason to
prevent it from optimizing it.
If gep offset 'x' is unknown, it is an open question, but if gep has
inbounds the folding should still be allowed otherwise the result is poison.

On Fri, Apr 24, 2020 at 6:42 PM Sjoerd Meijer via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I don't think you can safely assume an address or range for a global at
> compile-time and make decisions based on this. It's the linker's job to
> calculate an address for this, and the final physical address is another
> thing that depends on your platform, e.g a hosted environment, or a an
> embedded system with all sorts of different memories where you can place
> data. But I am always a bit out of my comfort zone with linkers, so others
> my have a better answer.
> Cheers.
> ------------------------------
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Sam
> Kvasov via llvm-dev <llvm-dev at lists.llvm.org>
> *Sent:* 24 April 2020 01:17
> *To:* llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>
> *Subject:* [llvm-dev] Pointer comparison folding
> Hi,
> I am looking at some code that does address comparisons to check whether a
> given pointer is within a certain memory range. For example:
> if (0xff00 <= &a[x] && &a[x] < 0xffff)
> This results in IR like:
>   %2 = getelementptr inbounds [100 x i32], [100 x i32]* @a, i32 0, i32 %0,
> !dbg !9
>   %3 = icmp uge i32* %2, inttoptr (i32 65280 to i32*), !dbg !10
>   %4 = icmp ult i32* %2, inttoptr (i32 65535 to i32*), !dbg !11
> Suppose that 'a' is a global and we know the range of addresses where it
> can be allocated. Is it a safe transformation to use that range and
> constant fold the icmps? Is so, is it still safe if the gep offset 'x' is
> unknown?
> Regards,
> Sam
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


Juneyoung Lee
Software Foundation Lab, Seoul National University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200425/09682460/attachment.html>

More information about the llvm-dev mailing list