Re: [PATCH] x86, msr: Save an instruction in amd64 rdtsc, rdmsr, and

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 18, 2015 at 12:24:29PM -0700, Andy Lutomirski wrote:
> Weird.  Why does gcc think that an "=a" constraint on a 32-bit
> variable results in undefined high bits?

Probably precaution...

> I just compiled this:
> 
> unsigned long long merge(unsigned int low, unsigned int high)
> {
>     return (low) | ((unsigned long long)(high) << 32);
> }
> 
> and I get this:
> 
> merge:
>         movq    %rsi, %rax
>         movl    %edi, %edi

What guarantees you that the high 32-bits of %rdi, i.e. @low, are
cleared? Or is the caller required to do so? If so, I can't find that
passage in the ABI doc...

>         salq    $32, %rax
>         orq     %rdi, %rax
>         ret
> 
> Huh?  Clang does the same thing.
> 
> In fact, if I compile:
> 
> extern unsigned int func(void);
> 
> unsigned long long promote(void)
> {
>     return func();
> }
> 
> I get:
> 
> promote:
>         subq    $8, %rsp
>         call    func
>         addq    $8, %rsp
>         movl    %eax, %eax

zero-extend the int?

>         ret
> 
> Now I'm extra confused. Do I just misunderstand the ABI, or are both
> clang and gcc missing an obvious optimization?

I don't see anything out of the ordinary but you'll tell me :)

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-x86_64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux ia64]     [Linux Kernel]     [DCCP]     [Linux ARM]     [Yosemite News]     [Linux SCSI]     [Linux Hams]
  Powered by Linux