[llvm-dev] What is ConstantExpr?

John Criswell via llvm-dev llvm-dev at lists.llvm.org
Fri Mar 17 06:26:37 PDT 2017


On 3/17/17 6:32 AM, Zeson Wu wrote:
> Still thanks John.
>
> Another example is that
>
> int a;
>
> int main(){
> return 5+(long)(&a);
> }
>
> In O0 mode, IR is like blow
>
> @a = global i32 0, align 4
>
> ; Function Attrs: noinline norecurse nounwind
> define signext i32 @main() #0 {
>   %1 = alloca i32, align 4
>   store i32 0, i32* %1, align 4
>   ret i32 trunc (i64 add (i64 ptrtoint (i32* @a to i64), i64 5) to i32)
> }
>
> In O2 mode, IR is optimized as blow.
> @a = global i32 0, align 4
>
> ; Function Attrs: norecurse nounwind readnone
> define signext i32 @main() local_unnamed_addr #0 {
>   ret i32 trunc (i64 add (i64 ptrtoint (i32* @a to i64), i64 5) to i32)
> }
>
> I mean what's the advantage of that pattern with constantexpr since it 
> is introduced in O2 mode?

I see the constant expression in both the -O0 and -O2 assembly files 
above; I don't think the optimizations are adding it to the code.

The advantage of the constant expression in this case is that LLVM can 
express the constant in an architecture-independent way.  First, you 
can't add a pointer to an integer, so a constant bitcast is needed.  
Second, even if the bitcast wasn't necessary, the value of "@a" hasn't 
been determined yet (as code generation hasn't occurred yet), so there 
is a need of representing the constant symbolically.

This is why constant expressions exist: they allow constants to be 
represented symbolically, and they allow for constants to be represented 
in a way that can type check.

> How does back end handle this pattern (which is a bitcast operator in 
> my last case in email before)?

After picking the location of the global variable "a", the backend 
should be able to simplify the constant expression into a single integer 
value.  Use clang -S to see the assembly code that LLVM generates; I 
suspect you'll see the constant expression simplified to a single 
constant value.

Regards,

John Criswell


>
> Thanks.
>
>
> 2017-03-11 0:32 GMT+08:00 John Criswell <jtcriswel at gmail.com 
> <mailto:jtcriswel at gmail.com>>:
>
>     On 3/9/17 11:28 PM, Zeson Wu wrote:
>>     OK. Could you give a specific example to illustrate what you are
>>     talking about and some comparison would be better.
>>
>>     Here is a example of ConstantExpr of BitCast.
>>
>>     target datalayout = "e-m:e-i64:64-n32:64"
>>     target triple = "powerpc64le-unknown-linux-gnu"
>>
>>     ; Function Attrs: norecurse
>>     define signext i32 @main() local_unnamed_addr #0 {
>>     entry:
>>       %call = tail call signext i32 @f([4 x i128] [i128 0, i128
>>     undef, i128 1334440659191554973911497130241, i128 undef], [1 x
>>     i128] [i128 bitcast (<16 x i8> <i8 2, i8 2, i8 2, i8 2, i8 2, i8
>>     2, i8 2, i8 2, i8 2, i8 2, i8 2, i8 2, i8 2, i8 2, i8 2, i8 2> to
>>     i128)], i32 signext 16)
>>       ret i32 %call
>>     }
>>
>>
>>     declare signext i32 @f([4 x i128], [1 x i128], i32 signext)
>>     local_unnamed_addr #1
>>
>>     I am thinking about why the result of bitcast is not computed
>>     directly after O2 optimization. What is the backend supposed to
>>     handle this constantexpr? Is there any advantage to do this?
>
>     The bitcast exists because the LLVM IR has type information; when
>     you bitcast a constant from one type to another, its value doesn't
>     change, but its static type does.  It's essentially a way of
>     expressing the same constant but with a different static type.
>
>     Also, please keep conversations on the list instead of emailing me
>     directly.  That way, others can benefit from the conversation and
>     can chime in if needed.
>
>     Regards,
>
>     John Criswell
>
>>
>>
>>     2017-03-09 22:39 GMT+08:00 John Criswell <jtcriswel at gmail.com
>>     <mailto:jtcriswel at gmail.com>>:
>>
>>         On 3/9/17 8:28 AM, Zeson Wu via llvm-dev wrote:
>>>         Hi, All.
>>>
>>>         Does anybody know about ConstantExpr in llvm? What's it?
>>>         Since it always appears after llvm optimization such as -O2
>>>         level, what is it supposed to be to codegen? I am wondering
>>>         it represents constant value which can be determined or
>>>         computed at compile-time(actually is link-time) to improve
>>>         performance. Although we do not know the actual constant
>>>         value util the object file is linked.
>>
>>         You're pretty much got it.  A Constant Expression
>>         (ConstantExpr) is simply a constant value.  Since some
>>         constant values depend upon architecture-dependent features
>>         (e.g., structure layout, pointer size, etc.), LLVM provides
>>         the ConstantExpr to represent them in a (more or less)
>>         architecture-independent way.
>>
>>         For example, a GEP with constant indices on an internal
>>         global variable will always compute the same value; it is a
>>         constant.  However, we use a GEP ConstantExpr to represent
>>         it; the backend code generator converts it to the appropriate
>>         numerical constant when generating native code.
>>
>>         For more information on the ConstantExpr, please see the LLVM
>>         Language Reference Manual
>>         (http://llvm.org/docs/LangRef.html#constant-expressions
>>         <http://llvm.org/docs/LangRef.html#constant-expressions>).
>>
>>         Regards,
>>
>>         John Criswell
>>
>>>
>>>         Here is a my example, but there is still existing code to
>>>         compute value in run-time.
>>>
>>>         cat a.C
>>>         int n=5;
>>>         int main(){
>>>           long a = (long)&n+7;
>>>           int b = a;
>>>           return b;
>>>         }
>>>
>>>         clang++ a.C  -c -O2 -emit-llvm -S;cat a.ll
>>>         ; ModuleID = 'a.C'
>>>         target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
>>>         target triple = "x86_64-apple-macosx10.12.0"
>>>
>>>         @n = global i32 5, align 4
>>>
>>>         ; Function Attrs: norecurse nounwind readnone ssp uwtable
>>>         define i32 @main() #0 {
>>>           ret i32 trunc (i64 add (i64 ptrtoint (i32* @n to i64), i64
>>>         7) to i32)
>>>         }
>>>
>>>         clang++ a.C  -c -O2;objdump -d a.O
>>>
>>>         a.O:file format Mach-O 64-bit x86-64
>>>
>>>         Disassembly of section __TEXT,__text:
>>>         _main:
>>>                0:55 pushq%rbp
>>>                1:48 89 e5 movq%rsp, %rbp
>>>                4:48 8d 05 00 00 00 00 leaq(%rip), %rax
>>>                b:83 c0 07 *addl$7, %eax*
>>>                e:5d popq%rbp
>>>                f:c3 retq
>>>
>>>         I am confused about what is its functionality in llvm?
>>>
>>>         Thanks.
>>>         ---------
>>>
>>>         Zeson
>>>
>>>
>>>         _______________________________________________
>>>         LLVM Developers mailing list
>>>         llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>>         http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>         <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>
>>         -- 
>>         John Criswell
>>         Assistant Professor
>>         Department of Computer Science, University of Rochester
>>         http://www.cs.rochester.edu/u/criswell
>>         <http://www.cs.rochester.edu/u/criswell>
>>
>>     -- 
>>     Zeson
>
>     -- 
>     John Criswell
>     Assistant Professor
>     Department of Computer Science, University of Rochester
>     http://www.cs.rochester.edu/u/criswell
>     <http://www.cs.rochester.edu/u/criswell>
>
> -- 
> Zeson

-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170317/d4ed02a7/attachment.html>


More information about the llvm-dev mailing list