ld2.acq - sign extension?

ld2.acq - sign extension?

[Jes Sorensen]

Hi,

Trying to figure out if it's GCC being broken or what else could be
causing this problem.

I am chasing an issue where the console hangs when I boot my self
compiled kernels under KVM. I have tracked down the problem to a
single instruction change in the vgacon driver, however if I
understand the rules correctly this specific change should not cause
any difference in code execution whatsoever?

Basically if I apply the below diff my code no longer works. However I
am under the impression that ld2.acq does sign extension? If thats the
case, does anybody have an explanation for why my bode breaks if I
don't perform the zxt2 instruction on the previously loaded register
before the comparison? Note the mov r19=r17 at the end, which should
mean there is no reason why this change should affect code flow
further down the lin...

Any input would be greatly appreciated, I have been trying to track
this down for a couple of weeks and I still don't get why this is
going wrong.

Thanks,
Jes


--- /tmp/vgacon-good.S  2008-05-16 06:09:08.000000000 -0500
+++ /tmp/vgacon-test2.S 2008-05-19 03:54:45.000000000 -0500
@@ -113,22 +113,22 @@
        ld2.acq r21 = [r18], 2
        ;;
        ld2.acq r16 = [r18]
        nop 0
        .mmi
        st2.rel [r8] = r20
        st2.rel [r18] = r22
        zxt2 r15 = r21
        .mii
-       ld2.acq r19 = [r8]
+       ld2.acq r17 = [r8]
        nop 0
        ;;
-       zxt2 r17 = r19
+       zxt2 r19 = r19
        .mib
        nop 0
        zxt2 r16 = r16
        nop 0
        ;;
        .mib
        cmp4.ne p8, p9 = r11, r17
        mov r19 = r17
        (p8) br.cond.dpnt .L8

Re: ld2.acq - sign extension?

[Andreas Schwab]

Jes Sorensen <jes@sgi.com> writes:

> Basically if I apply the below diff my code no longer works. However I
> am under the impression that ld2.acq does sign extension?

ld always zero extends.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: ld2.acq - sign extension?

[Jes Sorensen]

Andreas Schwab wrote:
> Jes Sorensen <jes@sgi.com> writes:
> 
>> Basically if I apply the below diff my code no longer works. However I
>> am under the impression that ld2.acq does sign extension?
> 
> ld always zero extends.

Hi Andreas,

Thats what I thought too, but do you have any explanation as to why
that patch I included makes a difference?

Thanks,
Jes

Re: ld2.acq - sign extension?

[Avi Kivity]

Jes Sorensen wrote:
> Andreas Schwab wrote:
>> Jes Sorensen <jes@sgi.com> writes:
>>
>>> Basically if I apply the below diff my code no longer works. However I
>>> am under the impression that ld2.acq does sign extension?
>>
>> ld always zero extends.
>
> Hi Andreas,
>
> Thats what I thought too, but do you have any explanation as to why
> that patch I included makes a difference?
>

r17 is used later on, so your patch makes it uninitialized (if I may 
venture to comment about an assembly language I know nothing about).

Maybe a bug in the instruction emulator?

-- 
error compiling committee.c: too many arguments to function

Re: ld2.acq - sign extension?

[Matthew Chapman]

Jes,

You mentioned that you're running on KVM... while I don't know much
about how KVM works, is that load instruction being intercepted and
emulated by any chance?  (Considering that it looks like something that
would be accessing hardware registers on a real machine.)  A bug in that
emulation could explain why it's behaving strangely...

Matt


On Mon, May 19, 2008 at 05:27:26AM -0400, Jes Sorensen wrote:
> Hi,
> 
> Trying to figure out if it's GCC being broken or what else could be
> causing this problem.
> 
> I am chasing an issue where the console hangs when I boot my self
> compiled kernels under KVM. I have tracked down the problem to a
> single instruction change in the vgacon driver, however if I
> understand the rules correctly this specific change should not cause
> any difference in code execution whatsoever?
> 
> Basically if I apply the below diff my code no longer works. However I
> am under the impression that ld2.acq does sign extension? If thats the
> case, does anybody have an explanation for why my bode breaks if I
> don't perform the zxt2 instruction on the previously loaded register
> before the comparison? Note the mov r19=r17 at the end, which should
> mean there is no reason why this change should affect code flow
> further down the lin...
> 
> Any input would be greatly appreciated, I have been trying to track
> this down for a couple of weeks and I still don't get why this is
> going wrong.
> 
> Thanks,
> Jes
> 
> 
> --- /tmp/vgacon-good.S  2008-05-16 06:09:08.000000000 -0500
> +++ /tmp/vgacon-test2.S 2008-05-19 03:54:45.000000000 -0500
> @@ -113,22 +113,22 @@
>         ld2.acq r21 = [r18], 2
>         ;;
>         ld2.acq r16 = [r18]
>         nop 0
>         .mmi
>         st2.rel [r8] = r20
>         st2.rel [r18] = r22
>         zxt2 r15 = r21
>         .mii
> -       ld2.acq r19 = [r8]
> +       ld2.acq r17 = [r8]
>         nop 0
>         ;;
> -       zxt2 r17 = r19
> +       zxt2 r19 = r19
>         .mib
>         nop 0
>         zxt2 r16 = r16
>         nop 0
>         ;;
>         .mib
>         cmp4.ne p8, p9 = r11, r17
>         mov r19 = r17
>         (p8) br.cond.dpnt .L8
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ld2.acq - sign extension?

[Jes Sorensen]

Matthew Chapman wrote:
> Jes,
> 
> You mentioned that you're running on KVM... while I don't know much
> about how KVM works, is that load instruction being intercepted and
> emulated by any chance?  (Considering that it looks like something that
> would be accessing hardware registers on a real machine.)  A bug in that
> emulation could explain why it's behaving strangely...

Hi Matt,

That has to be the reason - I was sitting here being convinced it
wasn't emulated because it's not a priviledged instruction, but
obviously it is given it's accessing the emulated registers.

Next I need to figure out how thats handled, whether it's a KVM bug
a hypervisor bug ..... all this fun we are having.

Cheers,
Jes

Re: ld2.acq - sign extension?

[Jes Sorensen]

>>>>> "Avi" = Avi Kivity <avi@qumranet.com> writes:

Avi> Jes Sorensen wrote:
Avi> r17 is used later on, so your patch makes it uninitialized (if I
Avi> may venture to comment about an assembly language I know nothing
Avi> about).

Oh, on ia64 the sequence is [dest] = [src] so the register usage is
covered I believe.

Avi> Maybe a bug in the instruction emulator?

Yeah it smells like it, that or in QEMU. I am not quite sure who is
responsible for this part. Does QEMU just provide registers somewhere
else and the instruction emulation reads them out of the QEMU share
space, or is there some other magic going on?

Cheers,
Jes

RE: ld2.acq - sign extension?

[Xu, Anthony]

Jes Sorensen wrote:
> Avi> Maybe a bug in the instruction emulator?
> 
> Yeah it smells like it, that or in QEMU. I am not quite sure who is
> responsible for this part. Does QEMU just provide registers somewhere
> else and the instruction emulation reads them out of the QEMU share
> space, or is there some other magic going on?

This instruction access IO port of VGA or VGA framebuffer, so it will
trap into KVM,
It is qemu emuate this IO access, while it is kvm to emulate the
behavior of "zero extend" of ld2.acq.
Will fix it soon.


Zxt2 is not necessary after ld2.acq,

Thanks,
Anthony