From: Christophe R. <cs...@ca...> - 2007-07-01 10:29:55
Attachments:
foo.diff
|
Christophe Rhodes <cs...@ca...> writes: > Now, the clever x86-64 wizards have spent their time optimizing the > section in question; take a look at src/compiler/x86-64/call.lisp, at > the VOP definition for DEFAULT-UNKNOWN-VALUES. There are several > different codepaths there, to optimize the generated code for space in > various different circumstances. Unfortunately, it would appear that > the code generated for the last branch (when there are more than seven > values needed, as in your test case) is wonky in some fashion. > > (I wouldn't expect that fixing this is very hard, but first I need to > page back in my understanding of x86 assembler and the sbcl calling > convention. It's been a while... :-) The attached patch fixes the problem, which seems to have been a relic of the old calling convention (changing the return address instead of using the carry flag to indicate multiple values). On the other hand, it removes the (presumed) optimization provided by jmp-short. Can x86-64 experts please comment? |
From: Christophe R. <cs...@ca...> - 2007-07-02 16:59:51
|
Christophe Rhodes <cs...@ca...> writes: > The attached patch fixes the problem, which seems to have been a relic > of the old calling convention (changing the return address instead of > using the carry flag to indicate multiple values). On the other hand, > it removes the (presumed) optimization provided by jmp-short. Can > x86-64 experts please comment? I've convinced myself that jmp-short was an artifact of the previous calling convention on x86 and x86-64, and so I've deleted it and merged the patch I sent as sbcl-1.0.7.9. Cheers, Christophe |