Re: Comparing lowtags: slightly inefficient assembly code

It's adding the fixnum's tag by shifting left.

My guess would be to write a function which translates directly to a VOP.
You can write any assembly code you wish there. See here for an example:
https://pvk.ca/Blog/2014/08/16/how-to-define-new-intrinsics-in-sbcl/

On the other hand, I'd recommend EQ/EQL/EQUAL/EQUALP for comparing objects
whose types aren't known to be anything more narrow than T.

ср, 30 апр. 2025 г., 23:03 David Scherfgen via Sbcl-help <
[email protected]>:

> The purpose of this code is to provide an "early exit" in a function that
> compares two objects X and Y - it's the #1 function in terms of number of
> calls and execution time in the application (determined by deterministic
> and statistical profiling). If X and Y have different lowtags, then the
> function can abort immediately. I can't tell whether the extra bit shifts
> cause significant performance issues, I'd have to compare it to the
> "optimal" code, but that's a bit difficult in practice.
>
> Am Mi., 30. Apr. 2025 um 21:51 Uhr schrieb Stas Boukarev <
> [email protected]>:
>
>> Is that causing you some unexpected performance issues?
>>
>> On Wed, Apr 30, 2025 at 10:50 PM David Scherfgen via Sbcl-help
>> <[email protected]> wrote:
>> >
>> > Hello,
>> >
>> > I have this SBCL-specific code to determine whether two objects X and Y
>> have the same lowtag:
>> >
>> > (defun same-lowtag-p (x y)
>> >   (= (sb-kernel:lowtag-of x) (sb-kernel:lowtag-of y)))
>> >
>> > The relevant part of the disassembly:
>> >
>> > MOV RDX, R8
>> > SHL RDX, 1
>> > AND EDX, 30
>> > MOV RDI, RSI
>> > SHL RDI, 1
>> > AND EDI, 30
>> > CMP RDI, RDX
>> >
>> > It shifts the address of X and Y to the left by 1 bit, then masks with
>> 30 (= 15 << 1), then compares.
>> > The bit shift is unnecessary. It could mask X and Y with 15 and
>> directly compare without shifting.
>> >
>> > Is there any (hacky, using internals) way to modify the Lisp function
>> so that it results in optimal assembly without bit shifts?
>> >
>> > Thank you.
>> >
>> > Best regards
>> > David Scherfgen
>> > _______________________________________________
>> > Sbcl-help mailing list
>> > [email protected]
>> > https://lists.sourceforge.net/lists/listinfo/sbcl-help
>>
> _______________________________________________
> Sbcl-help mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>

_______________________________________________
Sbcl-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-help