[llvm-dev] Where and how to report an optimisation issue that doesn't cause a crash
Ivan Kosarev via llvm-dev
llvm-dev at lists.llvm.org
Tue Oct 29 12:20:40 PDT 2019
Answering the second question, the new TBAA representation is a work in
progress; it's not mature enough to be enabled by default.
On 29/10/2019 19:55, אלכס לופ' wrote:
> So I have a couple of question regarding the approach provided by Chill.
>
> 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?
> 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?
> Thanks,
> Alex.
>
>
>
> ב אוק׳ 28, 2019 12:33, Ivan Kosarev כתב:
>
> 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/20191029/55900518/attachment.html>
More information about the llvm-dev
mailing list