This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH v3] gcc/config/tilegx/tilegx.c (tilegx_function_profiler): Save r10 to stack before call mcount
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Chris Metcalf <cmetcalf at mellanox dot com>, Chen Gang <chengang at emindsoft dot com dot cn>, Jeff Law <law at redhat dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Richard Henderson <rth at redhat dot com>, Mike Stump <mikestump at comcast dot net>, Walter Lee <walt at tilera dot com>, "peter dot maydell at linaro dot org" <peter dot maydell at linaro dot org>, Chen Gang <gang dot chen dot 5i5j at gmail dot com>
- Date: Sun, 23 Oct 2016 18:11:38 +0000
- Subject: Re: [PATCH v3] gcc/config/tilegx/tilegx.c (tilegx_function_profiler): Save r10 to stack before call mcount
- Authentication-results: sourceware.org; auth=none
- Authentication-results: mellanox.com; dkim=none (message not signed) header.d=none;mellanox.com; dmarc=none action=none header.from=hotmail.de;
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
Hi,
I don't know much about tilegx, but
I think the patch should work as is.
This is because the
Save r10 code is a bundle
{
addi sp, sp, -8
st sp, r10
}
which stores r10 at [sp] and subtracts 8 from sp.
The restore r10 code is actually two bundles:
addi sp, sp, 8
ld r10, sp
This just adds 8 to sp, and loads r10 from there.
I don't know how __mcount is implemented, it must
be some asm code, almost all functions save the
lr at [sp] when invoked, but I don't know if __mcount
does that at all, if it doesn't do that, then the
adjusting of sp might be unnecessary.
The only thing that might be a problem is that
the stack is always adjusted in multiples of 16
on the tilegx platform, see tilegx.h:
#define STACK_BOUNDARY 128
That is counted in bits, and means 16 bytes.
But your patch adjusts the stack only by 8.
Furthermore, I don't see how the stack unwinding will work
with this stack adjustment when no .cfi directives
are emitted, but that is probably not a big problem.
You might see a difference, when single-stepping
over the function entry.
Maybe a test case would be good as well.
Bernd.