[racket-dev] JIT question

From: Jon Zeppieri (zeppieri at gmail.com)
Date: Tue May 7 17:43:01 EDT 2013

Thank you!

On Tue, May 7, 2013 at 5:37 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> I think you're right: line 1851 is useless.
>
> I added line 1851 weeks after writing the surrounding code. At the time
> that I added line 1851, the real repair was changing line 1859 to use
> `dest' as the destination. I didn't pay enough attention to see that
> the slow path is a failure path, so no result handling is needed.
>
> Contrast to line 1879, which is the slow path for `integer->char'. Line
> 1879 is useful, because the slow-path can produce a result that is
> placed in JIT_R0, and that result must be moved into the `dest'
> register (if `dest' happens not to be JIT_R0 --- otherwise
> `jit_movr_p(dest, JIT_R0)' doesn't generate any code).
>
> At Tue, 7 May 2013 17:29:52 -0400, Jon Zeppieri wrote:
>> I realize that I should get a --disable-jit version running before
>> tackling this, but since I stumbled into it last night...
>>
>> In jitinline.c, at line 1834, there is code for generating a JIT-ted
>> version of char->integer. I think I understand all of it, except for
>> line 1851:
>>
>> 1851: jit_movr_p(dest, JIT_R0);
>>
>> If the initial test (at line 1846 succeeds, then we jump past this
>> instruction (although we might jump back later, if the type-tag test
>> (at 1853) fails (well, succeeds, I suppose). But, if we ever get to
>> the code at line 1849:
>>
>> (void)jit_calli(sjc.bad_char_to_integer_code);
>>
>> Then we're never going to return from there... I think. So, I'm not
>> sure what execution path the code could take where that move
>> instruction would matter. Also, assuming that instruction is
>> reachable, I still don't know what it's for.
>>
>> Can anyone (probably Matthew) enlighten me?
>>
>> -Jon
>> _________________________
>>   Racket Developers list:
>>   http://lists.racket-lang.org/dev

Posted on the dev mailing list.