Re: display word wrapping

[Juanma Barranquero]

On 31 May 2004 09:34:34 +0200
Eli Zaretskii <address@hidden> wrote:

> This probably means that the optimizer is not in itself the direct
> culprit here, as declaring img `volatile' should have prevented the
> compiler from keeping it in a register.

OTOH, I'm more and more convinced it is an optimizer bug...

> However, this observation:
> 
> > If I put
> > 
> >   __asm push img
> >   img->load_failed_p = img->type->load (f, img) == 0;
> >   __asm pop img
> > 
> > (which forces a reload of the edi register from the stored value of img),
> > it works.
> 
> seems to say that img is still in a register, even if declared
> `volatile'.  Could you please look at the machine code near the
> invocation of "img->type->load (f, img)" and see whether `volatile'
> changes something there, and if so, what?

It doesn't affect. Code generated with or without "volatile" is
byte-by-byte identical (I suppose the optimizer's assuming the variable
doesn't need to be really volatile, because it is a stack var whose
address is not taken).

The relevant code, with a (non-volatile) local img, is:

; 1629 :       img->load_failed_p = img->type->load (f, img) == 0;

  04e88 8b 47 38         mov     eax, DWORD PTR [edi+56]
  04e8b 57               push    edi
  04e8c ff 75 08         push    DWORD PTR _f$[ebp]
  04e8f ff 50 08         call    DWORD PTR [eax+8]
  04e92 83 c4 0c         add     esp, 12                        ; 0000000cH
  04e95 f7 d8            neg     eax
  04e97 1b c0            sbb     eax, eax
  04e99 40               inc     eax
  04e9a 89 47 3c         mov     DWORD PTR [edi+60], eax

edi contains img.  Note that it is not reloaded after the call to [eax+8]

The code, for a static (non-volatile) img:

; 1629 :       img->load_failed_p = img->type->load (f, img) == 0;

  04e9f a1 00 00 00 00   mov     eax, DWORD PTR address@hidden@@address@hidden
  04ea4 8b 48 38         mov     ecx, DWORD PTR [eax+56]
  04ea7 50               push    eax
  04ea8 ff 75 08         push    DWORD PTR _f$[ebp]
  04eab ff 51 08         call    DWORD PTR [ecx+8]
  04eae 8b 3d 00 00 00
        00               mov     edi, DWORD PTR address@hidden@@address@hidden
  04eb4 83 c4 0c         add     esp, 12                        ; 0000000cH
  04eb7 f7 d8            neg     eax
  04eb9 1b c0            sbb     eax, eax
  04ebb 40               inc     eax
  04ebc 89 47 3c         mov     DWORD PTR [edi+60], eax

(the register usage is different, but note the load to edi after the
call...)

> But such a workaround needs
> to be more clever than the push/pop pair above, since it needs to
> update img->load_failed_p AFTER restoring img, not before it.

Yes, I know. I was just testing different local/static situations.

> IIUC, this boils down to calling gif_load (since the image file is
> GIF), right?

Yeah, but it happens with all libraries.

                                                                Juanma