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

<div dir='rtl'><div dir="ltr">Hi David,<br
/><br /></div>
<div dir="ltr"> </div>
<div dir="ltr">Thanks for your reply. The fact that
"queue_ptr->queue[queue_ptr->wr_idx++]" could be somewhere in
the object pointed by "queue_ptr" came to my mind too.</div>
<div dir="ltr">I also added this in the stackoverflow question
at the bottom.</div>
<div dir="ltr">In such case, I assumed, that if I change the
struct "queue_t" to have an array of "event_t" instead of
just pointer to "event_t", like this:</div>
<div dir="ltr"> </div>
<div dir="ltr">
<pre class="lang-c prettyprint
prettyprinted"><code><span
class="kwd">typedef</span> <span
class="kwd">struct</span>
<span class="pun">{</span>
    <span class="typ">event_t</span>                    
<span class="typ">queue</span><span
class="pun">[</span><span
class="lit">256</span><span
class="pun">];</span> <span class="com">//
changed from pointer to array with max size</span>
    <span class="typ">size_t</span><span
class="pln">                      size</span><span
class="pun">;</span>
    <span class="typ">uint16_t</span><span
class="pln">                    num_of_items</span><span
class="pun">;</span>
    <span class="typ">uint8_t</span><span
class="pln">                     rd_idx</span><span
class="pun">;</span>
    <span class="typ">uint8_t</span><span
class="pln">                     wr_idx</span><span
class="pun">;</span>
<span class="pun">}</span> <span
class="typ">queue_t</span><span
class="pun">;</span></code><br /><br
/>there would be no valid way (without breaking the C standard definitions)
that "queue_ptr->queue[queue_ptr->wr_idx++]" ends up somewhere
inside "*queue_ptr", right?<br />However the generated assembly
code still contained the same re-reads...<br />Any idea why would this
happen even with the new "queue_t" struct definition?<br
/><br />P.S.<br />I can easily reproduce it and provide any
additional data which can be gathered during the compilation process, if it
helps.<br /><br />Thanks,<br />Alex.</pre>
</div>
<div id="gtx-trans" style="position: absolute; left: 914px;
top: 351px;"> </div></div>

Here's a simpler version which I believe still captures the essence of the
issue: https://godbolt.org/z/BUoLq1

Yep, looks like GCC manages this optimization and Clang does not - the
runtime bound on the array is stopping clang from going further here
(perhaps that's intentional - maybe to allow the array indexed store to
possibly exceed the bounds of the array and assign to 'size' that comes
after it - UB, but I don't know just how far non-strict aliasing goes)

Yeah, looks like it might be something like that ^ if you change the index
to be unsigned, and reorder the members so 'size' comes before the array
(so indexing into the array can't alias 'size'), you do get:
https://godbolt.org/z/Ax62Fv which avoids reloading size after the
assignment to the array.

‪On Thu, Oct 24, 2019 at 12:53 PM ‫אלכס לופ'‬‎ <alex_lop at walla.com>
wrote:‬
> Hi David,
>
>
> Thanks for your reply. The fact that
> "queue_ptr->queue[queue_ptr->wr_idx++]" could be somewhere
in the object
> pointed by "queue_ptr" came to my mind too.
> I also added this in the stackoverflow question at the bottom.
> In such case, I assumed, that if I change the struct "queue_t" to
have an
> array of "event_t" instead of just pointer to
"event_t", like this:
>
>
> typedef struct{
>     event_t                     queue[256]; // changed from pointer to
array with max size
>     size_t                      size;
>     uint16_t                    num_of_items;
>     uint8_t                     rd_idx;
>     uint8_t                     wr_idx;} queue_t;
>
> there would be no valid way (without breaking the C standard definitions)
that "queue_ptr->queue[queue_ptr->wr_idx++]" ends up somewhere
inside "*queue_ptr", right?
> However the generated assembly code still contained the same re-reads...
> Any idea why would this happen even with the new "queue_t" struct
definition?
>
> P.S.
> I can easily reproduce it and provide any additional data which can be
gathered during the compilation process, if it helps.
>
> Thanks,
> Alex.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191024/ae4fa492/attachment.html>