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

[Ivan Kosarev via llvm-dev]

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
>
> 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
> 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/20191027/8cdf05d0/attachment.html>