[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH] Add support for a helper with 7 arguments

From: Taylor Simpson
Subject: RE: [PATCH] Add support for a helper with 7 arguments
Date: Fri, 7 Feb 2020 12:43:48 +0000

> -----Original Message-----
> From: Richard Henderson <address@hidden>
> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]