<div dir="ltr">I don't think there's any particular set of recommendations for this specific missed optimization/issue - are you working in an environment where memory reads are exceptionally expensive (in comparison to all the other things that a compiler might optimize code for & might not do so perfectly (no compiler's perfect, even within the bounds of the language and non-standard extensions))? I think this falls under the general bucket of "write code" -> "optimize code". Use profilers, find the hot spots, look at the code to see if you can make it algorithmically better, look at the machine code if it comes to that & see if you can tweak the source to get the assembly you want, or hand-write portions, etc.<br><br>2) I'm guessing it's work-in-progress and might not be production-ready/tested yet</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">‪On Tue, Oct 29, 2019 at 10:57 AM ‫אלכס לופ'‬‎ <<a href="mailto:alex_lop@walla.com">alex_lop@walla.com</a>> wrote:‬<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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><br></div></div><blockquote style="margin:0px 0px 20px;border-top:1px solid rgb(224,224,224)"><br>ב אוק׳ 28, 2019 12:33, Ivan Kosarev כתב:<blockquote style="margin:0px 0px 20px;border-top:1px solid rgb(224,224,224)">

  
    
  
  
    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:<br>
    </div>
    <blockquote type="cite">     
      <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" target="_blank">https://godbolt.org/z/xFC4Rp</a>
                :<br>               <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>
              <br>
            </div>
          </div>
          
          <blockquote style="margin:0px 0px 20px;border-top:1px solid rgb(224,224,224)"><br>
            ב אוק׳ 27, 2019 17:47, Ivan Kosarev כתב:
            <blockquote style="margin:0px 0px 20px;border-top:1px solid rgb(224,224,224)">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>               <div style="font-size:9pt;font-family:Calibri,sans-serif">
                  <h3 style="background-color:rgb(255,255,255);font-size:10pt;border:1px dotted rgb(0,51,51);padding:0.8em"><span style="color:rgb(255,102,0)">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" target="_blank">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" target="_blank">llvm-dev@lists.llvm.org</a>

<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
              </blockquote>
              <br>
            </blockquote>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br>
  


<br></blockquote></blockquote><br></div>
</blockquote></div>