RE: limiting call clobbered registers for library functions
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. Thanks, Matthew
Re: pass_stdarg problem when run after pass_lim
On Thu, Jan 29, 2015 at 11:20 PM, Tom de Vries wrote: > On 29-01-15 18:25, Jakub Jelinek wrote: >> >> The stdarg pass can't grok too heavy optimizations, so if at all possible, >> don't schedule such passes early, and if you for some reason do, avoid >> optimizing in there the va_list related accesses. > > > This patch work for the example. > > In pass_lim1, I get: > ... > ;; Function gen_rtvec (gen_rtvec, funcdef_no=1, decl_uid=1841, cgraph_uid=1, > symbol_order=1) > > va_list_related_stmt_p: no simple_mem_ref > _15 = p.gp_offset; > va_list_related_stmt_p: no simple_mem_ref > _16 = p.reg_save_area; > va_list_related_stmt_p: no simple_mem_ref > p.gp_offset = _21; > va_list_related_stmt_p: no simple_mem_ref > _23 = p.overflow_arg_area; > va_list_related_stmt_p: no simple_mem_ref > p.overflow_arg_area = _25; > va_list_related_stmt_p: MOVE_IMPOSSIBLE > _15 = p.gp_offset; > va_list_related_stmt_p: MOVE_IMPOSSIBLE > _16 = p.reg_save_area; > va_list_related_stmt_p: MOVE_IMPOSSIBLE > _23 = p.overflow_arg_area; > gen_rtvec (int n) > ... I don't like adding more hacks to aid the stdarg pass. It's not required for GCC 5 anyway and for GCC 6 we should push the lowering change. Maybe you want to pick up the work? Thanks, Richard. > Thanks, > - Tom
Re: value not set via reference
On 30 January 2015 at 07:23, Conrad S wrote: > On 30 January 2015 at 16:58, James Dennett wrote: >> It's hardly just a loophole: C++ doesn't specify the order of evaluation, >> so the code is wrong (i.e., non-portable, as you've found). >> >> Arguably this is a design problem with IOStreams, given how >> tempting it can be to write code that assumes left-to-right evaluation, >> but it's not a compiler bug. > > Okay, but what is the reason for changing the "expected" > (left-to-right) order of evaluation? Is there an optimisation > benefit? Yes. IIUC Clang doesn't always order left-to-right, sometimes it reorders arguments because doing so avoids having to spill a register to memory so that the register can be reused for the evaluation of another argument. So yes, allowing the compiler to decide on the order of evaluation can have significant benefits. > If not, why change the order to something unexpected? There is no "change", you're presupposing a particular order, which is not a valid assumption.
Re: pass_stdarg problem when run after pass_lim
On 30-01-15 09:41, Richard Biener wrote: I don't like adding more hacks to aid the stdarg pass. It's not required for GCC 5 anyway and for GCC 6 we should push the lowering change. Richard, I agree that that's the best solution (the posted patch is just a solution that helps me along for now). 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? Thanks, - Tom
libgomp support for RTEMS
Hello, I would like to add support for libgomp for the RTEMS operating system. I likely cannot use the standard Pthread API for this in some places since I have to account for RTEMS specifics related to partitioned/clustered scheduling and the priority based scheduler. If I implement for example functions like this void gomp_init_thread_affinity (pthread_attr_t *attr, unsigned int place) outside of the GCC provided libgomp (e.g. in the RTEMS sources) can I choose an arbitrary license for this or do I have to use the GPLv3 with the GCC Runtime Library Exception for it? Is it possible to add a gomp_free() to complement the gomp_malloc() etc.? This would enable the usage of a dedicated heap for OpenMP in RTEMS. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: libgomp support for RTEMS
On Fri, Jan 30, 2015 at 12:14:26PM +0100, Sebastian Huber wrote: > Hello, > > I would like to add support for libgomp for the RTEMS operating system. I > likely cannot use the standard Pthread API for this in some places since I > have to account for RTEMS specifics related to partitioned/clustered > scheduling and the priority based scheduler. If I implement for example > functions like this > > void gomp_init_thread_affinity (pthread_attr_t *attr, unsigned int place) > > outside of the GCC provided libgomp (e.g. in the RTEMS sources) can I choose > an arbitrary license for this or do I have to use the GPLv3 with the GCC > Runtime Library Exception for it? > > Is it possible to add a gomp_free() to complement the gomp_malloc() etc.? > This would enable the usage of a dedicated heap for OpenMP in RTEMS. Why would you want to implement it outside of libgomp? libgomp has a config/ tree, so just add config/rtems/ in there and implement it in there. Jakub
Re: libgomp support for RTEMS
On 30/01/15 12:50, Jakub Jelinek wrote: On Fri, Jan 30, 2015 at 12:14:26PM +0100, Sebastian Huber wrote: >Hello, > >I would like to add support for libgomp for the RTEMS operating system. I >likely cannot use the standard Pthread API for this in some places since I >have to account for RTEMS specifics related to partitioned/clustered >scheduling and the priority based scheduler. If I implement for example >functions like this > >void gomp_init_thread_affinity (pthread_attr_t *attr, unsigned int place) > >outside of the GCC provided libgomp (e.g. in the RTEMS sources) can I choose >an arbitrary license for this or do I have to use the GPLv3 with the GCC >Runtime Library Exception for it? > >Is it possible to add a gomp_free() to complement the gomp_malloc() etc.? >This would enable the usage of a dedicated heap for OpenMP in RTEMS. Why would you want to implement it outside of libgomp? libgomp has a config/ tree, so just add config/rtems/ in there and implement it in there. RTEMS uses the same method for the thread model. It is easier to maintain since I don't have to build and install a new compiler just to change the libgomp support. The RTEMS API header file is not available during GCC build. I would like to make some parts application configurable via function pointers (e.g. the heap functions). On RTEMS we have a single address space for the operating system, support libraries and the application. In the application we have parts of different criticality and dynamic behaviour, so the management of dynamic memory is highly application dependent. Some systems must run months without a re-boot. I would like to add a config/rtems and implement most of the stuff inside the RTEMS source tree or let even the application provide the implementation. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Rename C files to .c in GCC source
Hello When I checked out from the trunk I saw that various files had .C capital extension. Its not a big issue.. but I wondered if they should be .c like regular source files? libitm\testsuite\libitm.c++\static_ctor.C libitm\testsuite\libitm.c++\dropref.C libitm\testsuite\libitm.c++\eh-1.C libitm\testsuite\libitm.c++\throwdown.C I'm not on this list, so could you keep my email address included in any replies. Regards, Jonny -- Jonny j...@jguk.org
FOSDEM talk on GCC MELT (Lisp devroom)
Hello All
(sorry for the self-promotion)
I'm giving tomorrow january 31st 2015, at FOSDEM2015 (Lisp Dev Room) an
hour talk about GCC MELT
MELT is a Lispy domain specific language (implemented as a
GPLv3+licensed, FSF copyrighted, meta-plugin for GCC) to extend and
customize the GCC compiler.
About the GCC compiler, see http://gcc.gnu.org/
About MELT, see http://gcc-melt.org/
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: pass_stdarg problem when run after pass_lim
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.
Ciao,
Michael.
Index: gimplify.c
===
--- gimplify.c (revision 216512)
+++ gimplify.c (working copy)
@@ -9001,6 +9001,39 @@ dummy_object (tree type)
return build2 (MEM_REF, type, t, t);
}
+/* Call the target expander for evaluating a va_arg call of VALIST
+ and TYPE. */
+
+tree
+gimplify_va_arg_internal (tree valist, tree type, location_t loc,
+ gimple_seq *pre_p, gimple_seq *post_p)
+{
+ tree have_va_type = TREE_TYPE (valist);
+ have_va_type = targetm.canonical_va_list_type (have_va_type);
+
+ /* Make it easier for the backends by protecting the valist argument
+ from multiple evaluations. */
+ if (TREE_CODE (have_va_type) == ARRAY_TYPE)
+{
+ /* For this case, the backends will be expecting a pointer to
+TREE_TYPE (abi), but it's possible we've
+actually been given an array (an actual TARGET_FN_ABI_VA_LIST).
+So fix it. */
+ if (TREE_CODE (TREE_TYPE (valist)) == ARRAY_TYPE)
+ {
+ tree p1 = build_pointer_type (TREE_TYPE (have_va_type));
+ valist = fold_convert_loc (loc, p1,
+build_fold_addr_expr_loc (loc, valist));
+ }
+
+ gimplify_expr (&valist, pre_p, post_p, is_gimple_val, fb_rvalue);
+}
+ else
+gimplify_expr (&valist, pre_p, post_p, is_gimple_min_lval, fb_lvalue);
+
+ return targetm.gimplify_va_arg_expr (valist, type, pre_p, post_p);
+}
+
/* Gimplify __builtin_va_arg, aka VA_ARG_EXPR, which is not really a
builtin function, but a very special sort of operator. */
@@ -9027,8 +9060,7 @@ gimplify_va_arg_expr (tree *expr_p, gimp
/* Generate a diagnostic for requesting data of a type that cannot
be passed through `...' due to type promotion at the call site. */
- if ((promoted_type = lang_hooks.types.type_promotes_to (type))
- != type)
+ if ((promoted_type = lang_hooks.types.type_promotes_to (type)) != type)
{
static bool gave_help;
bool warned;
@@ -9062,36 +9094,28 @@ gimplify_va_arg_expr (tree *expr_p, gimp
*expr_p = dummy_object (type);
return GS_ALL_DONE;
}
- else
+ else if (optimize && !optimize_debug)
{
- /* Make it easier for the backends by protecting the valist argument
-from multiple evaluations. */
- if (TREE_CODE (have_va_type) == ARRAY_TYPE)
+ tree tmp, tag;
+ gimple call;
+ tmp = build_fold_addr_expr_loc (loc, valist);
+ if (gimplify_arg (&tmp, pre_p, loc) == GS_ERROR)
+ return GS_ERROR;
+ tag = build_int_cst (build_pointer_type (type), 0);
+ call = gimple_build_call_internal (IFN_VA_ARG, 2, tmp, tag);
+ gimple_seq_add_stmt (pre_p, call);
+ if (VOID_TYPE_P (type))
{
- /* For this case, the backends will be expecting a pointer to
-TREE_TYPE (abi), but it's possible we've
-actually been given an array (an actual TARGET_FN_ABI_VA_LIST).
-So fix it. */
- if (TREE_CODE (TREE_TYPE (valist)) == ARRAY_TYPE)
- {
- tree p1 = build_pointer_type (TREE_TYPE (have_va_type));
- valist = fold_convert_loc (loc, p1,
-build_fold_addr_expr_loc (loc,
valist));
- }
-
- gimplify_expr (&valist, pre_p, post_p, is_gimple_val, fb_rvalue);
+ *expr_p = NULL;
+ return GS_ALL_DONE;
}
- else
- gimplify_expr (&valist, pre_p, post_p, is_gimple_min_lval, fb_lvalue
Re: Rename C files to .c in GCC source
> On Jan 30, 2015, at 4:22 AM, Jonny Grant wrote: > > Hello > > When I checked out from the trunk I saw that various files had .C > capital extension. Its not a big issue.. but I wondered if they should > be .c like regular source files? No because they are c++ code so capital C is correct. Thanks, Andrew > > libitm\testsuite\libitm.c++\static_ctor.C > libitm\testsuite\libitm.c++\dropref.C > > libitm\testsuite\libitm.c++\eh-1.C > libitm\testsuite\libitm.c++\throwdown.C > > I'm not on this list, so could you keep my email address included in > any replies. > > Regards, Jonny > > -- > Jonny j...@jguk.org
Re: Rename C files to .c in GCC source
On 30/01/15 17:09, pins...@gmail.com wrote: On Jan 30, 2015, at 4:22 AM, Jonny Grant wrote: Hello When I checked out from the trunk I saw that various files had .C capital extension. Its not a big issue.. but I wondered if they should be .c like regular source files? No because they are c++ code so capital C is correct. Ok, I see. Only ever encountered files called .cpp. Regards, Jonny
Re: Rename C files to .c in GCC source
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++).
Re: Rename C files to .c in GCC source
> Am 30.01.2015 um 21:30 schrieb Jonny Grant : > > > > On 30/01/15 17:09, pins...@gmail.com wrote: >> >> >> >> >>> On Jan 30, 2015, at 4:22 AM, Jonny Grant wrote: >>> >>> Hello >>> >>> When I checked out from the trunk I saw that various files had .C >>> capital extension. Its not a big issue.. but I wondered if they should >>> be .c like regular source files? >> >> No because they are c++ code so capital C is correct. > > Ok, I see. Only ever encountered files called .cpp. > > Regards, Jonny „Valid“ extensions happen to be .cpp, .cxx, .c++, .cc or .C. Although, .C can, in rare occasions, also speak about a pre-processed .c file. But finding this case is like searching a needle in a haystack. :)
Re: Rename C files to .c in GCC source
> 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.
Re: Rename C files to .c in GCC source
On 30 January 2015 at 21:39, DJ Delorie wrote:
>
> 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++).
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.
Re: Rename C files to .c in GCC source
On 30 January 2015 at 22:24, Kevin Ingwersen (Ingwie Phoenix) wrote: > Apple’s HFS is, on a default OS X install, case insensitive. Which doesn't matter, see my previous reply. > But .c++ is valid. .cxx sounds pretty straight forward to me, since people > also use the $CXX variable. We already use .C and .cc in GCC sources, so even if we needed to change it, it would probably be better to use .cc for consistency rather than add a third extension.
Re: Rename C files to .c in GCC source
> Am 31.01.2015 um 02:57 schrieb Jonathan Wakely : > > On 30 January 2015 at 22:24, Kevin Ingwersen (Ingwie Phoenix) wrote: >> Apple’s HFS is, on a default OS X install, case insensitive. > > Which doesn't matter, see my previous reply. That is true; though its good to keep an eye out for it. >> But .c++ is valid. .cxx sounds pretty straight forward to me, since people >> also use the $CXX variable. > > We already use .C and .cc in GCC sources, so even if we needed to > change it, it would probably be better to use .cc for consistency > rather than add a third extension. Oh, I did not know this detail since I haven’t peered into the GCC source in a felt forever. Would make sense to use .cc then if it has already been used elsewhere in the source.
