<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 3/17/17 6:32 AM, Zeson Wu wrote:<br>
</div>
<blockquote
cite="mid:CALaRbYFMFh_wOoAggWr07OWurSEBx+=SeUy7XU-HaxPykzSNkQ@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>Still thanks John.<br>
<br>
</div>
Another example is that <br>
<br>
int a;<br>
<br>
int main(){<br>
return 5+(long)(&a);<br>
}<br>
<br>
</div>
In O0 mode, IR is like blow<br>
<br>
@a = global i32 0, align 4<br>
<br>
; Function Attrs: noinline norecurse nounwind<br>
define signext i32 @main() #0 {<br>
%1 = alloca i32, align 4<br>
store i32 0, i32* %1, align 4<br>
ret i32 trunc (i64 add (i64 ptrtoint (i32* @a to i64),
i64 5) to i32)<br>
}<br>
<br>
</div>
In O2 mode, IR is optimized as blow.<br>
@a = global i32 0, align 4<br>
<br>
; Function Attrs: norecurse nounwind readnone<br>
define signext i32 @main() local_unnamed_addr #0 {<br>
ret i32 trunc (i64 add (i64 ptrtoint (i32* @a to i64), i64
5) to i32)<br>
}<br>
<br>
</div>
I mean what's the advantage of that pattern with constantexpr
since it is introduced in O2 mode?<br>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:CALaRbYFMFh_wOoAggWr07OWurSEBx+=SeUy7XU-HaxPykzSNkQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div> How does back end handle this pattern (which is a bitcast
operator in my last case in email before)?<br>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
Regards,<br>
<br>
John Criswell<br>
<br>
<br>
<blockquote
cite="mid:CALaRbYFMFh_wOoAggWr07OWurSEBx+=SeUy7XU-HaxPykzSNkQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
Thanks.<br>
<div>
<div>
<div>
<div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2017-03-11 0:32 GMT+08:00 John Criswell
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:jtcriswel@gmail.com" target="_blank">jtcriswel@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote">
<div><span class="">
<div class="m_-5294476307183461368moz-cite-prefix">On
3/9/17 11:28 PM, Zeson Wu wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>OK. Could you give a specific example to
illustrate what you are talking about and some
comparison would be better.<br>
<br>
Here is a example of ConstantExpr of BitCast.<br>
<br>
target datalayout = "e-m:e-i64:64-n32:64"<br>
target triple = "powerpc64le-unknown-linux-<wbr>gnu"<br>
<br>
; Function Attrs: norecurse<br>
define signext i32 @main() local_unnamed_addr #0
{<br>
entry:<br>
%call = tail call signext i32 @f([4 x i128]
[i128 0, i128 undef, i128
133444065919155497391149713024<wbr>1, 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)<br>
ret i32 %call<br>
}<br>
<br>
<br>
declare signext i32 @f([4 x i128], [1 x i128],
i32 signext) local_unnamed_addr #1<br>
<br>
</div>
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?<br>
</div>
</div>
</blockquote>
<br>
</span> 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.<br>
<br>
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.<br>
<br>
Regards,<br>
<br>
John Criswell
<div>
<div class="h5"><br>
<blockquote type="cite">
<div dir="ltr"><br>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2017-03-09 22:39
GMT+08:00 John Criswell <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:jtcriswel@gmail.com"
target="_blank">jtcriswel@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote">
<div><span
class="m_-5294476307183461368gmail-">
<div
class="m_-5294476307183461368gmail-m_3227547216749959667moz-cite-prefix">On
3/9/17 8:28 AM, Zeson Wu via
llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi, All.
<div><br>
</div>
<div>Does anybody know about
ConstantExpr in llvm? What's it?</div>
<div>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.<br>
</div>
</div>
</blockquote>
<br>
</span> 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.<br>
<br>
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.<br>
<br>
For more information on the
ConstantExpr, please see the LLVM
Language Reference Manual (<a
moz-do-not-send="true"
href="http://llvm.org/docs/LangRef.html#constant-expressions"
class="m_-5294476307183461368gmail-m_3227547216749959667moz-txt-link-freetext"
target="_blank">http://llvm.org/docs/LangRef.<wbr>html#constant-expressions</a>).<br>
<br>
Regards,<br>
<br>
John Criswell<br>
<br>
<blockquote type="cite">
<div>
<div
class="m_-5294476307183461368gmail-h5">
<div dir="ltr">
<div><br>
Here is a my example, but
there is still existing code
to compute value in run-time.<br>
<br>
<div>
<div>cat a.C</div>
<div>int n=5;</div>
<div>int main(){</div>
<div> long a =
(long)&n+7;</div>
<div> int b = a;</div>
<div> return b;</div>
<div>}<br>
<br>
<div>clang++ a.C -c -O2
-emit-llvm -S;cat a.ll</div>
<div>; ModuleID = 'a.C'</div>
<div>target datalayout =
"e-m:o-i64:64-f80:128-n8:16:32<wbr>:64-S128"</div>
<div>target triple =
"x86_64-apple-macosx10.12.0"</div>
<div><br>
</div>
<div>@n = global i32 5,
align 4</div>
<div><br>
</div>
<div>; Function Attrs:
norecurse nounwind
readnone ssp uwtable</div>
<div>define i32 @main() #0
{</div>
<div> ret i32 trunc (i64
add (i64 ptrtoint (i32*
@n to i64), i64 7) to
i32)</div>
<div>}</div>
<br>
<div>clang++ a.C -c
-O2;objdump -d a.O</div>
<div><br>
</div>
<div>a.O:<span
class="m_-5294476307183461368gmail-m_3227547216749959667gmail-Apple-tab-span">
</span>file format
Mach-O 64-bit x86-64</div>
<div><br>
</div>
<div>Disassembly of
section __TEXT,__text:</div>
<div>_main:</div>
<div> 0:<span
class="m_-5294476307183461368gmail-m_3227547216749959667gmail-Apple-tab-span">
</span>55 <span
class="m_-5294476307183461368gmail-m_3227547216749959667gmail-Apple-tab-span">
</span>pushq<span
class="m_-5294476307183461368gmail-m_3227547216749959667gmail-Apple-tab-span">
</span>%rbp</div>
<div> 1:<span
class="m_-5294476307183461368gmail-m_3227547216749959667gmail-Apple-tab-span">
</span>48 89 e5 <span
class="m_-5294476307183461368gmail-m_3227547216749959667gmail-Apple-tab-span">
</span>movq<span
class="m_-5294476307183461368gmail-m_3227547216749959667gmail-Apple-tab-span">
</span>%rsp, %rbp</div>
<div> 4:<span
class="m_-5294476307183461368gmail-m_3227547216749959667gmail-Apple-tab-span">
</span>48 8d 05 00 00 00
00 <span
class="m_-5294476307183461368gmail-m_3227547216749959667gmail-Apple-tab-span">
</span>leaq<span
class="m_-5294476307183461368gmail-m_3227547216749959667gmail-Apple-tab-span">
</span>(%rip), %rax</div>
<div> b:<span
class="m_-5294476307183461368gmail-m_3227547216749959667gmail-Apple-tab-span">
</span>83 c0 07 <span
class="m_-5294476307183461368gmail-m_3227547216749959667gmail-Apple-tab-span">
</span><b>addl<span
class="m_-5294476307183461368gmail-m_3227547216749959667gmail-Apple-tab-span">
</span>$7, %eax</b></div>
<div> e:<span
class="m_-5294476307183461368gmail-m_3227547216749959667gmail-Apple-tab-span">
</span>5d <span
class="m_-5294476307183461368gmail-m_3227547216749959667gmail-Apple-tab-span">
</span>popq<span
class="m_-5294476307183461368gmail-m_3227547216749959667gmail-Apple-tab-span">
</span>%rbp</div>
<div> f:<span
class="m_-5294476307183461368gmail-m_3227547216749959667gmail-Apple-tab-span">
</span>c3 <span
class="m_-5294476307183461368gmail-m_3227547216749959667gmail-Apple-tab-span">
</span>retq</div>
<br>
</div>
</div>
<div>I am confused about what
is its functionality in
llvm?<br>
</div>
<div><br>
</div>
Thanks.<br>
---------<br>
</div>
<div><br>
<div
class="m_-5294476307183461368gmail-m_3227547216749959667gmail_signature">
<div dir="ltr">Zeson<br>
</div>
</div>
</div>
</div>
<br>
<fieldset
class="m_-5294476307183461368gmail-m_3227547216749959667mimeAttachmentHeader"></fieldset>
<br>
</div>
</div>
<pre>______________________________<wbr>_________________
LLVM Developers mailing list
<a moz-do-not-send="true" href="mailto:llvm-dev@lists.llvm.org" class="m_-5294476307183461368gmail-m_3227547216749959667moz-txt-link-abbreviated" target="_blank">llvm-dev@lists.llvm.org</a>
<a moz-do-not-send="true" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="m_-5294476307183461368gmail-m_3227547216749959667moz-txt-link-freetext" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><span class="m_-5294476307183461368gmail-HOEnZb">
</span></pre><span class="m_-5294476307183461368gmail-HOEnZb">
</span></blockquote><span class="m_-5294476307183461368gmail-HOEnZb">
<p>
</p>
<pre cols="72" class="m_-5294476307183461368gmail-m_3227547216749959667moz-signature">--
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
<a moz-do-not-send="true" href="http://www.cs.rochester.edu/u/criswell" class="m_-5294476307183461368gmail-m_3227547216749959667moz-txt-link-freetext" target="_blank">http://www.cs.rochester.edu/u/<wbr>criswell</a></pre>
</span></div>
</blockquote></div>
--
<div class="m_-5294476307183461368gmail_signature"><div dir="ltr">Zeson
</div></div>
</div></div></div>
</blockquote>
<p>
</p><pre class="m_-5294476307183461368moz-signature" cols="72">--
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
<a moz-do-not-send="true" class="m_-5294476307183461368moz-txt-link-freetext" href="http://www.cs.rochester.edu/u/criswell" target="_blank">http://www.cs.rochester.edu/u/<wbr>criswell</a></pre></div></div></div></blockquote></div>
--
<div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Zeson
</div></div>
</div>
</blockquote>
<p>
</p><pre class="moz-signature" cols="72">--
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
<a class="moz-txt-link-freetext" href="http://www.cs.rochester.edu/u/criswell">http://www.cs.rochester.edu/u/criswell</a></pre></body></html>