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 _________________________ Racket Developers list: http://lists.racket-lang.org/dev
