Improved compiler macro about enhanced-boolean

[ruricolist]

It did result in an improved expansion in SBCL when I wrote it, but when I check the disassembly it doesn't anymore, so I withdraw my suggestion.

[Hexstream]

Thank you for the feedback, although I'm afraid I don't quite understand.

Note that enhanced-boolean:boolean is declaimed inline and its ftype is declared. I am confident that SBCL would intelligently use that information in most circumstances. I'm assuming there is no need to "trick" SBCL into detecting the boolean return type, since I already directly told SBCL (or any other conforming implementation) that the return type is boolean, and portably so.

The expected effect of the ftype declaration, especially along with the inline declaration, is that it is already as if each call to enhanced-boolean:boolean was enclosed in (the boolean). Because of the inline declaration, SBCL can already "see" in the function, so it has no need for the compiler macro, although no harm will be done if it does use it. And it doesn't even need to understand that (if foo t nil) (assuming no non-local exit in foo) always returns a boolean (since the ftype declaration already says it), although I suspect it might. Compiler macros must preserve the semantics of the function call, so SBCL can confidently rely on my declared return type.

Your comment in serapeum doesn't seem coherent to me, since if the compiler macro result does end up being used, then the "call" to true is therefore inherently eliminated, since it is explicitly inlined by the compiler macro. As far as I can tell, the "trick" your compiler macro uses probably just obscures the code for no reason, and might even result in slower code (but is guaranteed to result in slower compilation).

Please let me know if I missed anything, I certainly don't claim to be an optimization expert.

[Hexstream]

Thank you, perhaps SBCL might have had a performance bug at that time (or you might just have got confused, it happens to everyone). Was this very long ago?

[ruricolist]

According to git-blame it was August of 2017, so long enough.

[Hexstream]

At the pace SBCL is developing, that was ages ago, yes. ;)