On 16 March 2017 at 11:47, John Zhang <john.zh...@anu.edu.au> wrote: > Hi Carl, Armin, William, > I have thought about modifying the JIT code instruction set, descriptors and > runtime rewrite etc. to encode the MuTyped CFG (which is a further type and > ops specialisation towards the Mu MicroVM) for Mu back-end. But I presume > this will involve a large amount of work? Would this be the case? And thus > this wouldn’t be a good idea, right? >
The more of the metainterp you can make use of the better. I would start by trying to push your graphs through the codewriter and seeing how/if that fails. LLTyped graphs have gone to the effort to encode the types involved into the identifier of the operation, eg, you get float_abs and llong_rshift. If you are not able to do something like that, you can still pass constants as arguments to the operation, and then ignore them in the backend (or use them to generate a particular operation) and have the codewriter preserve them for analysis later. They will get recorded in the constant table on the jitcodes. For an example of this, note that indirect_call operations maintain a set of possible targets as their last argument; it might be illustrative to search for that name. I guess it is worth asking: What other operations are you finding difficult to type? I get that the lltype specialisation of new_ is one, and that address manipulation with composite offsets is another (though it turns out to always be well-typed in practice). -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely MAY reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without prior contractual agreement. _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
