Thank you!
On Tue, May 7, 2013 at 5:37 PM, Matthew Flatt <mfl...@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 _________________________ Racket Developers list: http://lists.racket-lang.org/dev
