not using push by gcc
Dear gcc developer,
I have a code like this:
#include
void foo(int x)
{
int y;
x++;
y = 4;
}
int main(void)
{
foo(2);
return 0;
}
and compiled with "gcc -o outexec srcfile.c" command.
when disassemble the file we see that sending argument to function
"foo" is done by
--
sub esp, 4
mov dword ptr [esp], 2
callfoo
--
instructions. why gcc doesn't use the "push" command like:
--
push 2
callfoo
--
?
Sincerely.
Re: gcc rodata regression
On Sat, Jan 31, 2015 at 05:09:29PM -0700, Simon Glass wrote:
> I have been fighting with a strange problem on ARM where gcc puts all
> the .rodata from a number of files lumped into a single .rodata
> section even when -fdata-sections is used.
>
> I searched and found a bug report here:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303
>
> which exactly describes the problem I see.
You could try this patch. I think there were still some problems with
it, there must have been some reason I didn't submit it. Cannot have
been just laziness :-P
Cheers,
Segher
>From 1c1ebc41fca45f497e019a5ab433c68d23010f31 Mon Sep 17 00:00:00 2001
Message-Id:
<1c1ebc41fca45f497e019a5ab433c68d23010f31.1422864485.git.seg...@kernel.crashing.org>
From: Segher Boessenkool
Date: Sat, 12 Oct 2013 15:41:50 -0700
Subject: [PATCH] Make mergeable read-only sections per-function, if requested.
---
gcc/varasm.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/gcc/varasm.c b/gcc/varasm.c
index 295c27d..ee57a45 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -740,6 +740,16 @@ default_no_function_rodata_section (tree decl
ATTRIBUTE_UNUSED)
return readonly_data_section;
}
+const char *
+function_mergeable_rodata_prefix (void)
+{
+ section *s = targetm.asm_out.function_rodata_section (current_function_decl);
+ if (SECTION_STYLE (s) == SECTION_NAMED)
+return s->named.name;
+ else
+return targetm.asm_out.mergeable_rodata_prefix;
+}
+
/* Return the section to use for string merging. */
static section *
@@ -761,7 +771,7 @@ mergeable_string_section (tree decl ATTRIBUTE_UNUSED,
const char *str;
HOST_WIDE_INT i;
int j, unit;
- const char *prefix = targetm.asm_out.mergeable_rodata_prefix;
+ const char *prefix = function_mergeable_rodata_prefix ();
char *name = (char *) alloca (strlen (prefix) + 30);
mode = TYPE_MODE (TREE_TYPE (TREE_TYPE (decl)));
@@ -814,7 +824,7 @@ mergeable_constant_section (enum machine_mode mode
ATTRIBUTE_UNUSED,
&& align <= 256
&& (align & (align - 1)) == 0)
{
- const char *prefix = targetm.asm_out.mergeable_rodata_prefix;
+ const char *prefix = function_mergeable_rodata_prefix ();
char *name = (char *) alloca (strlen (prefix) + 30);
sprintf (name, "%s.cst%d", prefix, (int) (align / 8));
--
1.8.1.4
Re: limiting call clobbered registers for library functions
On 01/30/2015 11:16 AM, Matthew Fortune wrote:
Yury Gribov writes:
On 01/29/2015 08:32 PM, Richard Henderson wrote:
On 01/29/2015 02:08 AM, Paul Shortis wrote:
I've ported GCC to a small 16 bit CPU that has single bit shifts. So
I've handled variable / multi-bit shifts using a mix of inline shifts
and calls to assembler support functions.
The calls to the asm library functions clobber only one (by const) or
two
(variable) registers but of course calling these functions causes all
of the standard call clobbered registers to be considered clobbered,
thus wasting lots of candidate registers for use in expressions
surrounding these shifts and causing unnecessary register saves in
the surrounding function prologue/epilogue.
I've scrutinized and cloned the actions of other ports that do the
same, however I'm unable to convince the various passes that only r1
and r2 can be clobbered by these library calls.
Is anyone able to point me in the proper direction for a solution to
this problem ?
You wind up writing a pattern that contains a call, but isn't
represented in rtl as a call.
Could it be useful to provide a pragma for specifying function register
usage? This would allow e.g. library writer to write a hand-optimized
assembly version and then inform compiler of it's binary interface.
Currently a surrogate of this can be achieved by putting inline asm code
in static inline functions in public library headers but this has it's
own disadvantages (e.g. code bloat).
This sounds like a good idea in principle. I seem to recall seeing something
similar to this in other compiler frameworks that allow a number of special
calling conventions to be defined and enable functions to be attributed to use
one of them. I.e. not quite so general as specifying an arbitrary clobber list
but some sensible pre-defined alternative conventions.
FYI a colleague from kernel mentioned that they already achieve this by
wrapping the actual call with inline asm e.g.
static inline int foo(int x) {
asm(
".global foo_core\n"
// foo_core accepts single parameter in %rax,
// returns result in %rax and
// clobbers %rbx
"call foo_core\n"
: "+a"(x)
:
: "rbx"
);
return x;
}
We still can't mark inline asm with things like __attribute__((pure)),
etc. though so it's not an ideal solution.
-Y
Re: pass_stdarg problem when run after pass_lim
On 30-01-15 14:11, Michael Matz wrote: Hi, On Fri, 30 Jan 2015, Tom de Vries wrote: Maybe you want to pick up the work? In principle yes, depending on the amount of work (at this point I have no idea what remains to be done and how long that would take me). Michael, are your patches posted somewhere? I don't think I ever sent them. Pasted below, from somewhen October last year. This essentially moves expanding va_arg to pass_stdarg. But it does not yet make use of the possibilities this would bring, namely throwing away a whole lot of fragile code in pass_stdarg that tries to recover from expanding va_arg too early. To avoid having to touch each backend it retains expanding va_arg as a tree expression that needs to go through the gimplifier, which can create new basic blocks that need to be discovered after the fact, so there's some shuffling of code in tree-cfg as well. I also seem to remember that there was a problem with my using temporaries of the LHS for the new va_arg internal call, some types can't be copied and hence no temporaries can be created. I can't seem to trigger this right now, but this needs to be dealt with somehow I think (but that requires the final lvalue be available when lowering the VA_ARG_EXPR). I think that's about it, hence, updating to current compiler, fixing the above problem (if it's still one), and then cleaning up pass_stdarg to make use of the availability of IFN_VA_ARG. Hi Michael, thanks for the patch. FYI I've: - added -ftree-stdarg-opt to be able to skip the va_list_gpr/fpr_size optimization (at least useful for developing this patch series) - split off the internal-fn.def part (since it triggers rebuild for a lot of files) - split off the part that is just refactoring (to get the patch containing the actual changes as small as possible) - pushed the series to vries/expand-va-arg-at-pass-stdarg Atm, at least these tests are failing: ... FAIL: gcc.target/x86_64/abi/callabi/vaarg-4a.c execution test FAIL: gcc.target/x86_64/abi/callabi/vaarg-5a.c execution test ... I've minimized the vaarg-4a.c failure, and added it as testcase to the patch series as gcc.target/x86_64/abi/callabi/vaarg-4.c. The problem is in this code: ... e = va_arg (argp, char *); e = va_arg (argp, char *); ... which is translated into: ... : argp.1 = argp_3(D); : argp.12_11 = &argp.1; _12 = *argp.12_11; _13 = _12 + 8; *argp.12_11 = _13; : argp.3 = argp_3(D); : argp.13_15 = &argp.3; _16 = *argp.13_15; _17 = _16 + 8; *argp.13_15 = _17; _19 = MEM[(char * *)_16]; e_8 = _19; ... We copy the value of argp to a temp (bb2), get the addres of the temp, and use it to read the value of the temp, and increment the value of the temp (bb5). However, subsequently we copy the _unmodified_ value of argp to a second temp (bb6), get the addres of that temp, and use it to read and increment (bb7). Obviously, the first and second read return the same value, while they shouldn't. Thanks, - Tom
Re: pass_stdarg problem when run after pass_lim
Hi, On Mon, 2 Feb 2015, Tom de Vries wrote: > I've minimized the vaarg-4a.c failure, and added it as testcase to the patch > series as gcc.target/x86_64/abi/callabi/vaarg-4.c. > > The problem is in this code: > ... > e = va_arg (argp, char *); > e = va_arg (argp, char *); > ... > > which is translated into: > ... > : > argp.1 = argp_3(D); > > : > argp.12_11 = &argp.1; > _12 = *argp.12_11; > _13 = _12 + 8; > *argp.12_11 = _13; > > : > argp.3 = argp_3(D); > > : > argp.13_15 = &argp.3; > _16 = *argp.13_15; > _17 = _16 + 8; > *argp.13_15 = _17; > _19 = MEM[(char * *)_16]; > e_8 = _19; > ... That looks like non-x86-64 ABI code. It builds with -mabi=ms, and it seems the particular path taken therein doesn't write back to the aplist if it's not locally created with va_start, but rather given as argument. Or rather, if it is not addressible (like with x86-64 ABI, where it's either addressible because of va_start, or is a pointer to struct due to array decay). The std_gimplify_va_arg_expr might need more changes. Ciao, Michael.
Re: Rename C files to .c in GCC source
On Fri, 2015-01-30 at 23:24 +0100, Kevin Ingwersen (Ingwie Phoenix)
wrote:
> > Am 30.01.2015 um 22:39 schrieb DJ Delorie :
> >
> >
> > pins...@gmail.com writes:
> >> No because they are c++ code so capital C is correct.
> >
> > However, we should avoid relying on case-sensitive file systems
> > (Windows) and use .cc or .cxx for C++ files ("+" is not a valid file
> > name character on Windows, so we can't use .c++).
>
> Apple’s HFS is, on a default OS X install, case insensitive. But .c++
> is valid. .cxx sounds pretty straight forward to me, since people also
> use the $CXX variable.
FWIW this bit the gcc-python-plugin when someone tried to build it on OS
X: I had a "foo.c" and a "foo.C" in the same directory, with different
content (can't remember the actual names, I think they were one of my
test cases).
IIRC this confused *git* on OS X no end (only one file could exist in
the working copy at once), until I fixed it by renaming the .C file
to .cc.
This error (albeit on my part) has rather turned me off ".C" files; I
use ".cc" in my own projects these days, fwiw. I think as a general
rule one should avoid upper case in filename suffixes, for this kind of
reason.
Dave
Re: Rename C files to .c in GCC source
On 01/02/15 16:34, Kevin Ingwersen (Ingwie Phoenix) wrote: Am 01.02.2015 um 17:09 schrieb Eli Zaretskii : Date: Sat, 31 Jan 2015 01:55:29 + From: Jonathan Wakely Cc: Andrew Pinski , "gcc@gcc.gnu.org" , Jonny Grant These files are only compiled by GCC's own build system, with GCC's own makefiles, so we know we invoke the C++ compiler and so the language isn't inferred from the file extension, and so we aren't relying on case-sensitive file systems. That is true for building GCC. But what about editors and other development tools? They _will_ be affected. Indeed. Atom keeps thinking .C is an actual „ANSI C“ thing. If I were to make a suggestion to the GCC dev’s, then I probably could also swiftly word it as: $ find gcc-src -name "*.C“ | while read f; do mv $f $(echo $f | sed 's/\.C/\.cxx/g’); done In other words; .cxx, .cpp or .cc seems like a solution that works across platforms. Since .cc is already used at some places, I would recommend that this is to be the extension to choose. One does not neccessarily need to make a dev apply hacks all over just to start development. Hello Is this a consensus agreement to rename those .C -> .cc ? Regards, Jonny
Re: Rename C files to .c in GCC source
On Mon, Feb 2, 2015 at 1:11 PM, Jonny Grant wrote: > > > On 01/02/15 16:34, Kevin Ingwersen (Ingwie Phoenix) wrote: >> >> >>> Am 01.02.2015 um 17:09 schrieb Eli Zaretskii : >>> Date: Sat, 31 Jan 2015 01:55:29 + From: Jonathan Wakely Cc: Andrew Pinski , "gcc@gcc.gnu.org" , Jonny Grant These files are only compiled by GCC's own build system, with GCC's own makefiles, so we know we invoke the C++ compiler and so the language isn't inferred from the file extension, and so we aren't relying on case-sensitive file systems. >>> >>> >>> That is true for building GCC. But what about editors and other >>> development tools? They _will_ be affected. >> >> >> Indeed. Atom keeps thinking .C is an actual „ANSI C“ thing. If I were to >> make a suggestion to the GCC dev’s, then I probably could also swiftly word >> it as: >> >> $ find gcc-src -name "*.C“ | while read f; do mv $f $(echo $f | sed >> 's/\.C/\.cxx/g’); done >> >> In other words; .cxx, .cpp or .cc seems like a solution that works across >> platforms. Since .cc is already used at some places, I would recommend that >> this is to be the extension to choose. >> >> One does not neccessarily need to make a dev apply hacks all over just to >> start development. > > > Hello > > Is this a consensus agreement to rename those .C -> .cc ? There are around 11k files that have the .C ending to them; all in the testsuite. I don't think it make sense to move them. Thanks, Andrew > > Regards, Jonny >
Re: limiting call clobbered registers for library functions
On 02/02/15 18:55, Yury Gribov wrote:
On 01/30/2015 11:16 AM, Matthew Fortune wrote:
Yury Gribov writes:
On 01/29/2015 08:32 PM, Richard Henderson wrote:
On 01/29/2015 02:08 AM, Paul Shortis wrote:
I've ported GCC to a small 16 bit CPU that has single bit
shifts. So
I've handled variable / multi-bit shifts using a mix of
inline shifts
and calls to assembler support functions.
The calls to the asm library functions clobber only one (by
const) or
two
(variable) registers but of course calling these functions
causes all
of the standard call clobbered registers to be considered
clobbered,
thus wasting lots of candidate registers for use in
expressions
surrounding these shifts and causing unnecessary register
saves in
the surrounding function prologue/epilogue.
I've scrutinized and cloned the actions of other ports that
do the
same, however I'm unable to convince the various passes
that only r1
and r2 can be clobbered by these library calls.
Is anyone able to point me in the proper direction for a
solution to
this problem ?
You wind up writing a pattern that contains a call, but isn't
represented in rtl as a call.
Could it be useful to provide a pragma for specifying
function register
usage? This would allow e.g. library writer to write a
hand-optimized
assembly version and then inform compiler of it's binary
interface.
Currently a surrogate of this can be achieved by putting
inline asm code
in static inline functions in public library headers but this
has it's
own disadvantages (e.g. code bloat).
This sounds like a good idea in principle. I seem to recall
seeing something
similar to this in other compiler frameworks that allow a
number of special
calling conventions to be defined and enable functions to be
attributed to use
one of them. I.e. not quite so general as specifying an
arbitrary clobber list
but some sensible pre-defined alternative conventions.
FYI a colleague from kernel mentioned that they already achieve
this by wrapping the actual call with inline asm e.g.
static inline int foo(int x) {
asm(
".global foo_core\n"
// foo_core accepts single parameter in %rax,
// returns result in %rax and
// clobbers %rbx
"call foo_core\n"
: "+a"(x)
:
: "rbx"
);
return x;
}
We still can't mark inline asm with things like
__attribute__((pure)), etc. though so it's not an ideal solution.
-Y
Thanks everyone.
I've finally settled on an extension of the solution offered by
Richard(from the SH port)
I've had to ...
1.write an expander that expands ...
a)short (bit count) constant shifts to an
instruction pattern that emits asm for one or more inline shifts
b)other constant shifts to another instruction
pattern that emits asm for a libary call and clobbers cc
c)variable shifts to another instruction pattern
that emits asm for a libary call and clobbers ccplus r2
then for compare elimination two other instruction patters
corresponding to b) and c) that set CC from a compare instead of
clobbering it.
I could have avoided the expander and used a single instruction
pattern for a)b)c) if if could have found a way to have
alternative dependent clobbers in an instruction pattern. I
investigated attributes but couldn't see how I would be able to
achieve what I needed. Also tried clobber (match_dup 2) but when
one of the alternatives has a constant for operands[2] the
clobber is accepted silently by the .md compiler but doesn't
actually clobber the non-constant alternatives.
A mechanism to implement alternative dependent clobbers would
have allowed all this to be represented in a much more succinct
and compact manner.
On another note... compare elimination didn't work for pattern c)
and on inspection I found this snippet in compare-elim.c
static bool
arithmetic_flags_clobber_p (rtx insn)
{
...
...
if (GET_CODE (pat) == PARALLEL && XVECLEN (pat, 0) ==2)
{
which of course rejects any parallel pattern with a main rtx and
more than one clobber (i.e. (c) above). So I changed this
function so that it accepts patterns where rtx's one and upwards
are all clobbers, one being cc. The resulting generated asm ...
ld r2,r4; r2 holds the shift
count, it will be clobbered to calculate an index into the
sequence of shift instructions
call__ashl_v; variable ashl
beq .L4; branch on result
ld r1,r3
If anyone can see any fault in this change please call out
Of course, the problem with using inline asm is that you have to
arrange for them to be included in EVERY compile and they don't
allow compare elimination to be easily implemented.
Paul.
Re: limiting call clobbered registers for library functions
On 2 February 2015 at 21:54, Paul Shortis wrote: > I could have avoided the expander and used a single instruction pattern for > a)b)c) if if could have found a way to have alternative dependent clobbers > in an instruction pattern. I investigated attributes but couldn't see how I > would be able to achieve what I needed. Also tried clobber (match_dup 2) but > when one of the alternatives has a constant for operands[2] the clobber is > accepted silently by the .md compiler but doesn't actually clobber the > non-constant alternatives. You can clobber one or more match_scratch with suitable constraint alternatives and let the register allocator / reload reserve the hard registers. Well, not really for cc, you'll just have to say you clobber it, and split away the unused clobber post-reload. That will not really give you less source code, but more uniform patterns prior to register allocation. That gives the rtl optimizers a better handle on the code. The effect is even more pronounced when you replace all hard register usage with pseudo register usage and appropriate constraints.
Re: Rename C files to .c in GCC source
On 2 February 2015 at 21:11, Jonny Grant wrote: > Is this a consensus agreement to rename those .C -> .cc ? No.
