[racket-dev] JIT question

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Tue May 7 17:37:46 EDT 2013

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.