From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwTEG-0004sR-32 for qemu-devel@nongnu.org; Wed, 11 Nov 2015 06:06:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwTEC-0004vO-SY for qemu-devel@nongnu.org; Wed, 11 Nov 2015 06:06:16 -0500 Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]:35148) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwTEC-0004v2-M3 for qemu-devel@nongnu.org; Wed, 11 Nov 2015 06:06:12 -0500 Received: by wmdw130 with SMTP id w130so108173802wmd.0 for ; Wed, 11 Nov 2015 03:06:11 -0800 (PST) References: From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: Date: Wed, 11 Nov 2015 11:06:10 +0000 Message-ID: <87fv0caj8d.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] ARM NEON function call tracing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Junaid Shuja , QEMU Developers Peter Maydell writes: > On 11 November 2015 at 07:51, Junaid Shuja wrote: >> Hi, >> I am working on ARM/NEON instructions. I want to know which neon helper >> function corresponds to the neon instructions. As a test case, I have a >> source file with loads of vadd.i32 instructions. I want to trace which neon >> helper functions is called. I used a very crude approach: printf in >> neon_add_u16 funtion and compiled source again. But no printf showed on >> program execution. I need help regarding tracing of neon helpers. > > Integer addition is a simple operation so we can do it directly > in the generated code; we don't need a helper for it, even as a > Neon instruction. Generally we only have helper functions for > operations that are too complicated to do directly inline. > So there isn't a simple "one neon instruction, one helper function" > mapping. Where we do have a helper function, the helper > may work on one "lane" of Neon data (meaning it gets called > more than once for each instruction) or it may work on several > lanes at once. > > To find out how we handle a particular Neon instruction, you need > to look at disas_neon_data_insn and see what it does with the > insn (it may be easiest to do this by putting a breakpoint on > it and stepping through with a debugger). Where this code calls > gen_helper_* functions, it is emitting generated code which will > later call the relevant helper at runtime. Random musing: I wonder how easy it would be to emit the helper function name in the out_asm dump? > > thanks > -- PMM -- Alex Bennée