[llvm-dev] What is ConstantExpr?
Zeson Wu via llvm-dev
llvm-dev at lists.llvm.org
Fri Mar 17 03:32:46 PDT 2017
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?
How does back end handle this pattern (which is a bitcast operator in my
last case in email before)?
Thanks.
2017-03-11 0:32 GMT+08:00 John Criswell <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>:
>
>> 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
>> ).
>>
>> 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 listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>> --
>> John Criswell
>> Assistant Professor
>> Department of Computer Science, University of Rochesterhttp://www.cs.rochester.edu/u/criswell
>>
>> --
> Zeson
>
> --
> John Criswell
> Assistant Professor
> Department of Computer Science, University of Rochesterhttp://www.cs.rochester.edu/u/criswell
>
>
--
Zeson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170317/c6e5898c/attachment-0001.html>
More information about the llvm-dev
mailing list