[llvm-dev] Where and how to report an optimisation issue that doesn't cause a crash

[Ivan Kosarev via llvm-dev]

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.


On 27/10/2019 20:23, אלכס לופ' wrote:
> "...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."
> So what about this case https://godbolt.org/z/xFC4Rp :
>
> struct S {
>     int a[256];
>     int b;
> };
> int f(struct S *p, unsigned char i) {
>     if (p->b)
>         return42;
>     p->a[i] = 3;
>     return p->b;
> }
> "p->b" is re-read althoug the index "i" cannot acces beyond the array 
> boundary. What went wrong here?
> Thanks,
> Alex.
>
>
>
>     ב אוק׳ 27, 2019 17:47, Ivan Kosarev כתב:
>
>         Hi Momchil,
>
>         > That seems like something that Clang can do by itself for access
>         > tags for index expressions with member arrays: state that they
>         > access the offset in the struct that corresponds to the first
>         > array element, so unknown indices would still conservatively
>         > alias between each other, but not with other struct members.
>
>         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.
>
>         -- 
>         Regards,
>         Ivan
>
>
>
>         On 26/10/2019 23:39, Momchil Velikov via llvm-dev wrote:
>
>
>                   CAUTION:**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 ReportSpam at accesssoftek.com
>                   <mailto:ReportSpam at accesssoftek.com>
>
>             Using the shorter test case:
>
>                 struct S {
>                   int a[3];
>                   int b;
>                 };
>
>                 int f(struct S *p, int i) {
>                   if (p->b)
>                     return 42;
>
>                   p->a[i] = 3;
>                   return p->b;
>                 }
>
>             one can see that the the TBAA metadata loses information
>             about the array member:
>
>                 !4 = !{!"S", !5, i64 0, !7, i64 12}
>                 !5 = !{!"omnipotent char", !6, i64 0}
>
>             The "new struct path TBAA" looks better, it seems to say
>             "there are 12 bytes of
>             `int`s at offset 0 in struct S"
>
>             (Command line was ./bin/clang -target armv7m-eabi -O2 -S
>             y.c -emit-llvm -Xclang
>             -new-struct-path-tbaa)
>
>
>                 !3 = !{!4, !7, i64 12, i64 4}
>                 !4 = !{!5, i64 16, !"S", !7, i64 0, i64 12, !7, i64
>             12, i64 4}
>                 !5 = !{!6, i64 1, !"omnipotent char"}
>                 !6 = !{!"Simple C/C++ TBAA"}
>                 !7 = !{!5, i64 4, !"int"}
>                 !8 = !{!7, !7, i64 0, i64 4}
>
>             but then, the access tag for the store to the array
>
>
>                 %arrayidx = getelementptr inbounds %struct.S,
>             %struct.S* %p, i32 0, i32 0, i32 %i
>                 store i32 3, i32* %arrayidx, align 4, !tbaa !8
>
>             says just "it's in int" and there it still a redundant load:
>
>                 f:
>                     ldr     r2, [r0, #12]
>                     cmp     r2, #0
>                     itt     ne
>                     movne   r0, #42
>                     bxne    lr
>                     movs    r2, #3
>                     str.w   r2, [r0, r1, lsl #2]
>                     ldr     r0, [r0, #12]
>                     bx      lr
>
>             So, I manually hacked the metadata too look like:
>
>                 !8 = !{!4, !7, i64 0, i64 4}
>
>             i.e. as if we access the first element of the array.
>
>             Running that through `opt -O2` and `llc` yields:
>
>                 f:
>                     ldr     r2, [r0, #12]
>                     cmp     r2, #0
>                     iteee   ne
>                     movne   r0, #42
>                     moveq   r2, #3
>                     streq.w r2, [r0, r1, lsl #2]
>                     moveq   r0, #0
>                     bx      lr
>
>             That seems like something that Clang can do by itself for
>             access tags for index
>             expressions with member arrays: state that they access the
>             offset in the struct
>             that corresponds to the first array element, so unknown
>             indices would still
>             conservatively alias between each other, but not with
>             other struct members.
>
>             Thoughts? Pitfalls? I may give it a shot.
>             ~chill
>             --
>             Compiler scrub, Arm
>
>             _______________________________________________
>             LLVM Developers mailing list
>             llvm-dev at lists.llvm.org  <mailto:llvm-dev at lists.llvm.org>
>
>             https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191028/8938cfce/attachment.html>