> -----Original Message----- > From: Richard Henderson <richard.hender...@linaro.org> > > But I encourage you to re-think your purely mechanical approach to the > hexagon > port. It seems to me that you should be doing much more during the > translation > phase so that you can minimize the number of helpers that you require. >
There are a couple of things we could do - Short term: Add #ifdef's to the generated code so that the helper isn't compiled when there is a fWRAP_<tag> defined. There are currently ~500 instructions where this is the case. - Long term: Integrate rev.ng's approach that uses flex/bison to parse the semantics and generate TCG code. - Long long term: A much more general approach will be to turn the C semantics code into LLVM IR and generate TCG from the IR. Also, note that being able to use either a helper or TCG code is extremely useful for debugging qemu-hexagon. When a test is failing and you suspect a bug in TCG generation, you can switch to the helper version and see if the test passes. There have been cases where I used binary search over the fWRAP definitions to figure out which one of them has the bug. Also, it can be very handy to be able to set a breakpoint inside the helper and examine the CPU state in the middle of TCG execution. Taylor
