<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Alex,<br>
<br>
This is an internal option used to test the new TBAA. As far as I'm
aware, there are some defects that may cause AA to yield incorrect
results under some conditions, so yes, as of today enabling it is
not safe. I'd be happy to have a chance to work further on this, but
currently there are no any plans. I know there are other people
interested in this work who may have some plans, though.<br>
<br>
<br>
<div class="moz-cite-prefix">On 29/10/2019 22:12, אלכס לופ' wrote:<br>
</div>
<blockquote type="cite"
cite="mid:%5E2ECE39BBB35B77DEAF953945D20E360D0C218E91@walla.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="rtl">
<div>
<div dir="rtl">
<div dir="ltr">Thanks Ivan,<br>
<br>
</div>
<div dir="ltr"> </div>
<div dir="ltr">Any guess what side effects it can cause? I
mean, this option is available today, right? Just not by
default. </div>
<div dir="ltr">So how can I see if this option causes
"damages"? Just by comparing the binary outputs with and
without it?</div>
<div dir="ltr"> </div>
<div dir="ltr">By the way, are there any plans to make this
option a default one in some future release? If yes, then
what release is the target?</div>
<div dir="ltr"> </div>
<div dir="ltr"> </div>
</div>
<section class="cust_msg_end"></section>
<blockquote style="margin: 0; margin-bottom: 20px; border-top:
1px solid #e0e0e0;"><br>
ב אוק׳ 29, 2019 21:20, Ivan Kosarev כתב:
<blockquote style="margin: 0; margin-bottom: 20px;
border-top: 1px solid #e0e0e0;">Answering the second
question, the new TBAA representation is a work in
progress; it's not mature enough to be enabled by default.<br>
<br>
<br>
<div>On 29/10/2019 19:55, אלכס לופ' wrote:</div>
<blockquote
cite="mid:%5E9712EEA03EA86AECAC9DA011245D35F28CB7923D@walla.com">
<div>
<div dir="rtl">
<div dir="ltr" align="left">
<div dir="ltr" align="left">So I have a couple of
question regarding the approach provided by
Chill.</div>
<div dir="ltr" align="left"><br>
1. How to prevent such memory re-reads in the
future? Is there any BKM (best known method) for
programming guidelines which could eliminate or
reduce those re-reads?</div>
<div dir="ltr" align="left">2. What could be the
downside of the flag -Xclang
-new-struct-path-tbaa? Why not using it by
default if it makes better aliasing analysis?</div>
<div dir="ltr" align="left"> </div>
<div dir="ltr" align="left">Thanks,</div>
<div dir="ltr" align="left">Alex. </div>
<br>
</div>
</div>
<section></section>
<blockquote style="margin: 0; margin-bottom: 20px;
border-top: 1px solid #e0e0e0;"><br>
ב אוק׳ 28, 2019 12:33, Ivan Kosarev כתב:
<blockquote style="margin: 0; margin-bottom: 20px;
border-top: 1px solid #e0e0e0;">It's just that the
work on the new TBAA machinery is not completed
and we do not have all the required logic for the
new representation in place.<br>
<br>
<br>
<div>On 27/10/2019 20:23, אלכס לופ' wrote:</div>
<blockquote
cite="mid:%5EBF2D89B43C699965E0B802DE2F492E563EFD477F@walla.com">
<div dir="rtl">
<div>
<div dir="rtl">
<div dir="ltr" align="left">
<div dir="ltr">"...The idea behind the
new representation was to address
existing limitations by giving the
TBAA accurate information about
accesses. If memory servers me, in
this specific case of an unknown
index, the tag shall refer to the
whole member array, which is supposed
to mean that all and any of its
elements can actually be accessed."</div>
<div dir="ltr"> </div>
<div dir="ltr">So what about this case <a
href="https://godbolt.org/z/xFC4Rp"
moz-do-not-send="true">https://godbolt.org/z/xFC4Rp</a>
:<br>
</div>
<div dir="ltr"> </div>
<div dir="ltr">
<div>struct S {</div>
<div> int a[256];</div>
<div> int b;</div>
<div>};</div>
<div> </div>
<div>int f(struct S *p, unsigned char
i) {</div>
<div> if (p->b)</div>
<div> return42;</div>
<div> </div>
<div> p->a[i] = 3;</div>
<div> return p->b;</div>
<div>}</div>
<div> </div>
<div>"p->b" is re-read althoug the
index "i" cannot acces beyond the
array boundary. What went wrong
here?</div>
<div> </div>
<div>Thanks,</div>
<div>Alex.</div>
</div>
<br>
</div>
</div>
<section></section>
<blockquote style="margin: 0; margin-bottom:
20px; border-top: 1px solid #e0e0e0;"><br>
ב אוק׳ 27, 2019 17:47, Ivan Kosarev כתב:
<blockquote style="margin: 0;
margin-bottom: 20px; border-top: 1px
solid #e0e0e0;">Hi Momchil,<br>
<br>
> That seems like something that
Clang can do by itself for access<br>
> tags for index expressions with
member arrays: state that they<br>
> access the offset in the struct
that corresponds to the first<br>
> array element, so unknown indices
would still conservatively<br>
> alias between each other, but not
with other struct members.<br>
<br>
Then all by-known-index array accesses
would need to be encoded as if there
were accessing the first element,
wouldn't they? The idea behind the new
representation was to address existing
limitations by giving the TBAA accurate
information about accesses. If memory
servers me, in this specific case of an
unknown index, the tag shall refer to
the whole member array, which is
supposed to mean that all and any of its
elements can actually be accessed.<br>
<br>
-- <br>
Regards,<br>
Ivan<br>
<br>
<br>
<br>
<div>On 26/10/2019 23:39, Momchil
Velikov via llvm-dev wrote:</div>
<blockquote
cite="mid:CAEjVhjRhVQ6PHA6G+O6zZtFeMf_c0jzcDR-PMDvrFXemN9+CCQ@mail.gmail.com">
<div style="font-size: 9pt;
font-family: 'Calibri',sans-serif;">
<h3 style="background-color:
#ffffff; font-size: 10pt; border:
1px dotted #003333; padding:
.8em;"><span style="color:
#ff6600;">CAUTION:<strong> </strong></span>This
email originated from outside of
the organization. Do not click
links or open attachments unless
you recognize the sender and know
the content is safe. If you
suspect potential phishing or spam
email, report it to <a
href="mailto:ReportSpam@accesssoftek.com"
moz-do-not-send="true">ReportSpam@accesssoftek.com</a></h3>
</div>
<div>
<div dir="ltr">
<div dir="ltr">
<div style="font-family:
monospace,monospace;
font-size: small;">Using the
shorter test case:<br>
<br>
struct S {<br>
int a[3];<br>
int b;<br>
};<br>
<br>
int f(struct S *p, int i)
{<br>
if (p->b)<br>
return 42;<br>
<br>
p->a[i] = 3;<br>
return p->b;<br>
}<br>
<br>
one can see that the the TBAA
metadata loses information
about the array member:<br>
<br>
!4 = !{!"S", !5, i64 0,
!7, i64 12}<br>
!5 = !{!"omnipotent char",
!6, i64 0}<br>
<br>
The "new struct path TBAA"
looks better, it seems to say
"there are 12 bytes of<br>
`int`s at offset 0 in struct
S"<br>
<br>
(Command line was ./bin/clang
-target armv7m-eabi -O2 -S y.c
-emit-llvm -Xclang<br>
-new-struct-path-tbaa)<br>
<br>
<br>
!3 = !{!4, !7, i64 12, i64
4}<br>
!4 = !{!5, i64 16, !"S",
!7, i64 0, i64 12, !7, i64 12,
i64 4}<br>
!5 = !{!6, i64 1,
!"omnipotent char"}<br>
!6 = !{!"Simple C/C++
TBAA"}<br>
!7 = !{!5, i64 4, !"int"}<br>
!8 = !{!7, !7, i64 0, i64
4}<br>
<br>
but then, the access tag for
the store to the array<br>
<br>
<br>
%arrayidx = getelementptr
inbounds %struct.S, %struct.S*
%p, i32 0, i32 0, i32 %i<br>
store i32 3, i32*
%arrayidx, align 4, !tbaa !8<br>
<br>
says just "it's in int" and
there it still a redundant
load:<br>
<br>
f:<br>
ldr r2, [r0, #12]<br>
cmp r2, #0<br>
itt ne<br>
movne r0, #42<br>
bxne lr<br>
movs r2, #3<br>
str.w r2, [r0, r1,
lsl #2]<br>
ldr r0, [r0, #12]<br>
bx lr<br>
<br>
So, I manually hacked the
metadata too look like:<br>
<br>
!8 = !{!4, !7, i64 0, i64
4}<br>
<br>
i.e. as if we access the first
element of the array.<br>
<br>
Running that through `opt -O2`
and `llc` yields:<br>
<br>
f:<br>
ldr r2, [r0, #12]<br>
cmp r2, #0<br>
iteee ne<br>
movne r0, #42<br>
moveq r2, #3<br>
streq.w r2, [r0, r1,
lsl #2]<br>
moveq r0, #0<br>
bx lr<br>
<br>
That seems like something that
Clang can do by itself for
access tags for index<br>
expressions with member
arrays: state that they access
the offset in the struct<br>
that corresponds to the first
array element, so unknown
indices would still<br>
conservatively alias between
each other, but not with other
struct members.<br>
<br>
Thoughts? Pitfalls? I may give
it a shot.</div>
<div style="font-family:
monospace,monospace;
font-size: small;"> </div>
<div style="font-family:
monospace,monospace;
font-size: small;">~chill</div>
<div style="font-family:
monospace,monospace;
font-size: small;"> </div>
<div style="font-family:
monospace,monospace;
font-size: small;">--</div>
<div style="font-family:
monospace,monospace;
font-size: small;">Compiler
scrub, Arm</div>
<div style="font-family:
monospace,monospace;
font-size: small;"> </div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:llvm-dev@lists.llvm.org" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</blockquote>
</blockquote>
</div>
</div>
</blockquote>
<br>
</blockquote>
</blockquote>
</div>
</blockquote>
<br>
</blockquote>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>