Re: [Sbcl-devel] is it possible to de-fixnumize instead of fixnumize in VOPs?

[Denys R. <rt...@ma...>]

Hi Nathan,

>> ;      2FE:       C1F802           SAR EAX, 2
>> ;      301:       83C007           ADD EAX, 7   ; x += 8
>> ;      304:       83C008           ADD EAX, 8   ; x += 8
>> ;      307:       83C009           ADD EAX, 9   ; x += 9
>> ;      30A:       C1E002           SHL EAX, 2
>> ;      30D:       83E82C           SUB EAX, 44   ; x -= 11
>> ;      310:       83E830           SUB EAX, 48   ; x -= 12
>> ;      313:       83E834           SUB EAX, 52   ; x -= 13
>> ;      316:       8BD0             MOV EDX, EAX
>> ;      318:       8D65F8           LEA ESP, [EBP-8]
>> ;      31B:       F8               CLC
>> ;      31C:       8B6DFC           MOV EBP, [EBP-4]
>> ;      31F:       C20400           RET 4
>>
>>
>> Taking a look at the assembly I see that:
>> 1. addition tends to work with untagged values while subtraction prefers
>> tagged versions.
>>     
>
> This is, in general, not true.  It happens to be true in this case,
> but I'm sure that it's possible to construct cases when subtraction is
> done untagged and addition is done tagged.  The compiler uses the same
> mechanism for determining what to do for addition and for subtraction.
Isn't it exactly what happens in this case? If you take a look at the assembler code above, 7, 8 and 9 are being added to an untagged value. Then the value becomes tagged and 11, 12 and 13 are being subtracted from it.

>> 2. division is a call to an external function (at least in this case)
>> and the call seems to be quite expensive
>>     
>
> Yes, this is because / in Common Lisp is "true division", not the
> dumbed-down version that one has in languages like C, and therefore
> can return rational numbers in the general case of fixnum division.
> If you use TRUNCATE--which is probably what you meant--SBCL will use
> an inlined version (which compiles to IDIV).
>   
Ah.. I should have thought about it.. Of course, it tries hard to give 
me an exact value, not a truncated one.
> Your example also suggests other ways in which the compiler could be improved:
>
> 1) The first three assignments to X are dead code; they should be eliminated;
> 2) The constant additions and subtractions should be combined into a
> single addition and subtraction--bonus points for folding the whole
> thing into (- X 12).
I agree, the compiler could be improved in sense that it could determine 
that the values are overwritten so there is no need to perform the 
operations. But I guess that would be quite complicated as it never 
knows if it is what should be done or not. This optimization could be 
much easier if LISP would be a purely functional language without any 
side effects. In our case, the change would be quite tricky I guess.

Regards,
Denys Rtveliashvili