bug#38407: 27.0.50; infinite loop with display of large file without newlines

[Robert Pluim]

>>>>> On Mon, 02 Dec 2019 11:27:10 +0100, Robert Pluim <rpluim@gmail.com> said:

>>>>> On Sun, 01 Dec 2019 19:45:11 +0200, Eli Zaretskii <eliz@gnu.org> said:
    Robert> bidi-inhibit-bpa nil:

    Robert> # Overhead  Command       Shared Object                  Symbol
    Robert> # ........  ............  .............................  
..........................................................
    Robert> #
    Robert>     96.59%  emacs         libc-2.29.so                   [.] 
__memmove_avx_unaligned_erms
    Robert>      0.22%  emacs         emacs                          [.] 
mark_object
    Robert>      0.17%  emacs         emacs                          [.] 
composition_compute_stop_pos
    Robert>      0.12%  emacs         emacs                          [.] 
re_match_2_internal

So further messing with perf leads me to the following code in
move_it_in_display_line_to:

        {
          if (it->line_wrap == WORD_WRAP && it->area == TEXT_AREA)
            {
              if (IT_DISPLAYING_WHITESPACE (it))
                may_wrap = true;
              else if (may_wrap)
                {
                  /* We have reached a glyph that follows one or more
                     whitespace characters.  If the position is
                     already found, we are done.  */
                  if (atpos_it.sp >= 0)
                    {
                      RESTORE_IT (it, &atpos_it, atpos_data);
                      result = MOVE_POS_MATCH_OR_ZV;
                      goto done;
                    }
                  if (atx_it.sp >= 0)
                    {
                      RESTORE_IT (it, &atx_it, atx_data);
                      result = MOVE_X_REACHED;
                      goto done;
                    }
                  /* Otherwise, we can wrap here.  */
                  SAVE_IT (wrap_it, *it, wrap_data);          <=====
                  may_wrap = false;
                }
            }
        }

That SAVE_IT is what causes the __memmove_avx_unaligned_erms to show
up so high in the trace (via bidi_shelve_cache).

Robert