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

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

> >>>>> 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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.