Re: [Xen-devel] libxc: Casting of xen virtual address type xen_vaddr_t to signed int64 type: (int64_t)vaddr

[Viktor Mitin <viktor.mitin.19@xxxxxxxxx>]

> >>>>> For this reason it is better to avoid implementation-defined code.
> >>>> Well, ideally we'd like to get away without using implementation
> >>>> defined behavior. But I'm afraid we're quite far from that, and
> >>>> we'd not always be willing to accept the worse source and/or
> >>>> binary code that would be needed to avoid it.
> >>> How about using the next one-liner to avoid implementation-defined code :
> >>>
> >>> //Returns true in case when the top left 17 bits are all zero or are all 
> >>> one
> >>> return ((!(vaddr >> 47)) || (((vaddr >> 47)&0x1FFFF) == 0x1FFFF))
> >> Have you tried compiling these two examples and seeing how they differ?
> >>
> > Yes, I've tried it with the next draft test code.
> > The result looks ok, however it takes time to check all 64bits values
> > one by one...
> > Do you see any issues with new one-liner?
>
> Jan already identified the issue in the other thread, and my suggestion
> here was to inspect the generated assembly, which you'll observe is
> substantially more complicated.
>
> However, this thread isn't being productive.  You're clearly wanting to
> change this expression, and the maintainers see no reason to.

What it the reason to optimize performance (if any)
in a cost of 'implementation-defined code' usage?
It seems 'correctness' (including not using implementation-defined code)
of the code is higher priority than code performance. No?
Is this function had been noticed to be performance bottleneck?

> So, what problem are you actually trying to solve?

Well, it looks like this code may not work in case of another compiler usage.
However, if maintainers see no reason to change it, it is ok.

Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel