Re: Proposing switch -fsmart-pointers
On Oct 8, 2012, at 5:17 PM, Andrew Haley wrote:
> On 10/06/2012 11:59 AM, _ wrote:
>> Not that I think that STL/Boost are not great solutions for many
>> problems out there.
>> But the fact is that there is and always will be c/c++ code that can't
>> and will not use it.
>
> But surely the set of people refusing to use C++ smart pointers is the
> same set that will refuse to use your -fsmart-pointers.
It all boils down whether they are othodox or just simply pragmatic. I am
optimist and belive in second :)
>
>> C or C like templateless C++ code is still domain of most os /
>> drivers source code out there.
>> Just go agead and try to ask Linus to wrap all pointers to stl
>> templates ;D
>
> And he'd have the same response to -fsmart-pointers. Face it, the
> only real differences a compiler builtin would bring are:
>
> 1. A fossilized "smart pointer type".
> 2. A different declaration syntax.
Now imagine you have 300 developers with varying experience or ability to work
under pressure.
You will have 100 libs to manage. And for each lot of patch reviews.
Now which way you decide to go
Way A: manual cleanup. 30
Proc A {
Alloc resource 1
If alloc failed return error
Process resource 1
If problem with processing and alloc successfull release resource 1 and
exit
Alloc 100 different resources
}
>
> Andrew.
Re: Proposing switch -fsmart-pointers
Ahh ... sorry for that incomplete mail. I lost my right hand in
paragliding accident 2 months ago. And writing mail with one hand on
tablet is kinda weird. Again sorry .;(
Here is the complete version.
On Mon, Oct 8, 2012 at 5:17 PM, Andrew Haley wrote:
> On 10/06/2012 11:59 AM, _ wrote:
>> Not that I think that STL/Boost are not great solutions for many
>> problems out there.
>> But the fact is that there is and always will be c/c++ code that can't
>> and will not use it.
>
> But surely the set of people refusing to use C++ smart pointers is the
> same set that will refuse to use your -fsmart-pointers.
> On 10/06/2012 11:59 AM, _ wrote:
>> Not that I think that STL/Boost are not great solutions for many
>> problems out there.
>> But the fact is that there is and always will be c/c++ code that can't
>> and will not use it.
>
> But surely the set of people refusing to use C++ smart pointers is the
> same set that will refuse to use your -fsmart-pointers.
It all boils down whether they are othodox or just simply pragmatic. I
am optimist and belive in second :)
>
> Andrew.
>
>> C or C like templateless C++ code is still domain of most os /
>> drivers source code out there.
>> Just go agead and try to ask Linus to wrap all pointers to stl
>> templates ;D
>
> And he'd have the same response to -fsmart-pointers. Face it, the
> only real differences a compiler builtin would bring are:
>
> 1. A fossilized "smart pointer type".
> 2. A different declaration syntax.
>
> Andrew.
Now imagine you have 300 developers with varying experience or ability
to work under pressure.
You will have 100 libs to manage. And for each lot of patch reviews.
Now Tell me which way you decide to go in those projects?. A or B?
Way A: code is still C but with automatic cleanup like with static
objects, 100% of time of code review you focus on code logic. ie code
reviews are faster. Code is shorter faster to compile has the same
speed and a lot of less places to make bugs
Proc A {
alloc resource 1
if problem exit
process resource 1
If problem exit
alloc 100 different resources
if problem exit
process 100 resources with resource 1
if problem exit
release resources 1-50
process result with resources 50-100 and resource 1
if problem exit
return success
}
Way B: manual cleanup. 30. pretty much 50% of time spend on patch
review was spend on checking wheter no errors were made in releasing
of resources in error handling. The time you could had spend reviewing
other code logic.
The code is unnecessary long it's logic is les obvious and takes more
time to compile.
Proc {
alloc resource 1
if problem exit
process resource 1
If problem release resource 1 exit
alloc 100 different resources
if problem release resource 1 and those that didn't fail and exit
process 100 resources with resource 1
if problem release resource 1 and 100 resources and exit
release resources 1-50
process result with resources 50-100 and resource 1
if problem release resource 1 plus resource 50-100 and exit
release resources 50-100
release resource 1
return success
}
Re: DECL_STRUCT_FUNCTION(cgraphnode->decl) == NULL when attempting Link-Time Optimization in plugin
On Mon, Oct 8, 2012 at 11:29 PM, David Malcolm wrote:
> On Mon, 2012-10-08 at 18:21 +0200, Richard Guenther wrote:
>> On Mon, Oct 8, 2012 at 5:17 PM, David Malcolm wrote:
>> > I'm working on a static analysis extension to GCC via my
>> > gcc-python-plugin [1]
>> >
>> > The analysis is interprocedural (memory leak detection, as it happens).
>> > I have it working on one translation unit at a time, and I'm attempting
>> > to get it to work within Link Time Optimization so that it can see the
>> > interactions of all of the functions within a program or library, but
>> > I'm running what might be a bug (or I could be misunderstanding LTO).
>> >
>> > I have my plugin working within lto1, using "-flto" and "-fplugin"; my
>> > command line looks like:
>> > $ gcc -fPIC -shared -flto -g
>> > -fplugin=/home/david/coding/gcc-python/gcc-python/sm/python.so
>> > -fplugin-arg-python-script=examples/show-lto-supergraph.py
>> > tests/sm/lto/input-*.c --save-temps
>> >
>> > lto1 appears to be invoked twice by gcc. The first time, there are two
>> > passes:
>> > IPA_PASS named "whole-program"
>> > IPA_PASS named "inline"
>> > and "in_lto_p" is true.
>> >
>> > The second invocation has these passes, called per-function:
>> > GIMPLE_PASS "*free_cfg_annotations"
>> > GIMPLE_PASS "cplxlower0"
>> > GIMPLE_PASS "optimized"
>> > RTL_PASS "expand"
>> > GIMPLE_PASS "*rest_of_compilation"
>> > RTL_PASS "*init_function"
>> > ...etc.., normal rest of compilation from RTL stage onwards
>> > and "in_lto_p" is false.
>> >
>> > I've attempted to wire in my interprocedural analysis as a new IPA pass
>> > before or after "whole-program" and "inline" within the first invocation
>> > of lto1. In each case it is able to walk the callgraph, and the
>> > callgraph it sees appears to be correct: walking the linked list of
>> > cgraph_nodes the various cgraph_edge and cgraph_node are as expected,
>> > and for each cgraph_node, cgraph_node->decl is a non-NULL tree instance
>> > of type FUNCTION_DECL (as expected); I'm able to generate a graphviz
>> > rendering of the whole-program callgraph within lto1 from my plugin.
>> >
>> > However, for every cgraph_node, the
>> > DECL_STRUCT_FUNCTION(cgraph_node->decl) is (struct function*)NULL, which
>> > thwarts my code's attempt to look up the CFG of each underlying function
>> > and work on the underlying gimple.
>> >
>> > Looking with eu-readelf at the .o files shows these lto sections are
>> > present ("f" is the name of one of the functions that I'd like to access
>> > the gimple CFG of):
>> > $ eu-readelf -a input-f.o|grep lto
>> > [ 5] .gnu.lto_.inline.c8904cb9a96e7417 PROGBITS
>> > 006c 0026 0 E 0 0 1
>> > [ 6] .gnu.lto_f.c8904cb9a96e7417 PROGBITS 0092
>> > 0164 0 E 0 0 1
>> > [ 7] .gnu.lto_.cgraph.c8904cb9a96e7417 PROGBITS
>> > 01f6 0032 0 E 0 0 1
>> > [ 8] .gnu.lto_.vars.c8904cb9a96e7417 PROGBITS
>> > 0228 0012 0 E 0 0 1
>> > [ 9] .gnu.lto_.refs.c8904cb9a96e7417 PROGBITS
>> > 023a 0013 0 E 0 0 1
>> > [10] .gnu.lto_.statics.c8904cb9a96e7417 PROGBITS
>> > 024d 0014 0 E 0 0 1
>> > [11] .gnu.lto_.decls.c8904cb9a96e7417 PROGBITS
>> > 0261 01f3 0 E 0 0 1
>> > [12] .gnu.lto_.symtab.c8904cb9a96e7417 PROGBITS
>> > 0454 0011 0 E 0 0 1
>> > [13] .gnu.lto_.opts PROGBITS 0465 00e9
>> > 0 E 0 0 1
>> >25: 0001 1 OBJECT GLOBAL DEFAULT COMMON __gnu_lto_v1
>> > [2a] __gnu_lto_v1
>> >
>> > Are the (struct function*) and CFG meant to exist at this stage, and be
>> > in gimple form, and is DECL_STRUCT_FUNCTION meant to be non-NULL for
>> > functions in translation units that were compiled with -flto? (or have
>> > I misunderstood LTO?)
>>
>> It depends if you are in the WPA stage (lto1 was invoked with -fwpa)
>> in which case
>> no function bodies and thus no CFG is available at all, or if you are in
>> LTRANS
>> stage (lto1 was invoked with -fltrans) which see _part_ of the whole programs
>> callgraph and function bodies (and thus CFGs). As a workaround you probably
>> can make your example work by using -flto-partition=none which merges WPA
>> and LTRANS stages and pull in the wole program into a single link-time TU.
>
> Many thanks: "-fwpa" was indeed being passed by "gcc" to "lto1", and on
> adding "-flto-partition=none" to the gcc command line -fwpa goes away,
> and my plugin is able to see all of the gimple CFG from all of the .o
> files (and thus generate pretty graphviz renderings of the supergraph of
> all CFGs etc).
>
> FWIW the -fwpa behavior was surprising to me, and felt like something of
> a "gotcha". Based on my reading of
> http://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html#LTO-Overview
> I had
Cannot modify jumps after sched2
Hi, Is there any good way to define TARGET_CANNOT_MODIFY_JUMPS_P such that jumps are not modified after sched2? Or in other words, is there a way to recognize if sched2 has already been ran (sched2_completed, maybe)? Cheers, Paulo Matos
Re: Cannot modify jumps after sched2
Quoting Steven Bosscher : Paul Matos wrote (http://gcc.gnu.org/ml/gcc/2012-10/msg00123.html): Is there any good way to define TARGET_CANNOT_MODIFY_JUMPS_P such that jumps are not modified after sched2? No, there isn't. Well, you could add a target-specific pass after sched2 with the sole purpoe of setting a flag in the machine_function struct. For simpler prototyping work you could also play with PLUGIN_OVERRIDE_GATE and use a static/global variable in the target code for the flag.
Re: [RFC] Unsolicited usage of VFP registers for Cortex-M4F
Hi Joey Thank you for explanations. Now I have some comments and additional questions. Since now it will be a discussion rather than looking for help, I am re-routing the discussion to GCC mailing list. For those looking for the complete history, here is the context: http://gcc.gnu.org/ml/gcc-help/2012-10/msg00055.html On 09.10.2012 12:21, Joey Ye wrote: [snip] >> On 24.09.2012 12:30, Ilija Kocho wrote: >>> Hi colleagues >>> >>> In a course of implementing lazy context switching I the following >>> link come to me: >>> >>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0298a/DA >>> FIFGGE.html >>> [snip] >>> Therefore here are my questions: >>> >>> 1) Does GCC use VFP registers for holding data other than floating >>> point values (unsolicited VFP usage)? > It doesn't so far. Although GCC has no problem use FP for non-FP, the cost > model in ARM backend says using VFP isn't performing better than otherwise. > > For Cortex-M4F this isn't the best approach. I worked out a patch to tune > the cost model for M4F together with an option to enable/disable it. I'm > hoping to submit it later this year and it should enable Cortex-M4F to use > VFP extensively for non-FP data when option enabled. > >>> If (1) is true: >>> 1.1) What conditions, in addition to selecting -mfloat-abi=hard (or >>> softfp) shall cause such behaviour. I would appreciate some test case. > When the patch is upstreamed, and given that -ffpreg-for-nonfpdata is > provided, VFP will be used for non-FP data when ever register pressure is > high. > [snip] >> 1.4) Can it be disabled? I found no such command line option for ARM >> targets. > The command line will be as -f[no-]fpreg-for-nonfpdata According to current GCC conventions shoulfn't it begin with "m" i.e. -m[no]fpreg-for-nonfpdata ? >>> 2) Above quote states that -mfloat-abi=soft should be used for libs, but >>> ld refuses to link them with code produced with -mfloat-abi=hard even if >>> the libs do not use floating point operations. Is there a waay to tweak >>> this? > The quote isn't accurate nowadays. More and more libraries are built with > hard. Also a mechanism called multilib enables you to pick soft or hard > automatically according to linker command line Although I am not GCC expert I am aware of multilibs. Indeed, I have succeeded in building of GCC with a pretty rich multilib collection. But my point is: at present, due to floating point ABI incompatibility, we can't link functions/libs compiled with -mfloat-abi=soft flag to functions/libs compiled with -mfloat-abi=hard flag, regardless whether floating point is effectively in use or not. But, won't particular functions, that _do not_ use floating point, effectively have same ABI regardless of flags used (-mfloat-abi=soft or -mfloat-abi=hard)? Then shouldn't it be possible to link them to both /soft/ and /hard/ float-abi code? Any comments? Ilija
Re: Proposing switch -fsmart-pointers
On 10/09/2012 12:31 AM, Peter wrote: > > On Oct 8, 2012, at 5:17 PM, Andrew Haley wrote: > >> On 10/06/2012 11:59 AM, _ wrote: >>> Not that I think that STL/Boost are not great solutions for many >>> problems out there. >>> But the fact is that there is and always will be c/c++ code that can't >>> and will not use it. >> >> But surely the set of people refusing to use C++ smart pointers is the >> same set that will refuse to use your -fsmart-pointers. > > It all boils down whether they are othodox or just simply > pragmatic. I am optimist and belive in second :) Me too, but there's nothing more pragmatic about adding -fsmart-pointers to gcc when we already have smart pointers in C++. >>> C or C like templateless C++ code is still domain of most os / >>> drivers source code out there. >>> Just go agead and try to ask Linus to wrap all pointers to stl >>> templates ;D >> >> And he'd have the same response to -fsmart-pointers. Face it, the >> only real differences a compiler builtin would bring are: >> >> 1. A fossilized "smart pointer type". >> 2. A different declaration syntax. > > Now imagine you have 300 developers with varying experience or > ability to work under pressure. I don't have to imagine that. But of course you have to do the cleanup anyway because it is unlikely that in a large application it is appropriate to replace *every* use of a pointer with a smart pointer: some you do, some you don't. Andrew.
unsigned integers and the calculation of PI
Hi All, I'm trying to verify the 'fldpi' instruction on the Intel Processor. Hope you would like to have a look at the following piece of example code? Best Regards, Mischa. http://www.cyberfiber.org/sites/default/files/2012020314%20-%20algorithms%20on%20the%20intel%20processor%20-%20unsigned%20integers%20of%20extended%20order%20_64-bit_.tar.bz2
Re: Cannot modify jumps after sched2
Paulo Matos schrieb:
Hi,
Is there any good way to define TARGET_CANNOT_MODIFY_JUMPS_P such
that jumps are not modified after sched2?
Or in other words, is there a way to recognize if sched2 has already
been ran (sched2_completed, maybe)?
Such flags would be really helpful, but unfortunately there is nothing
like that. In an ideal world, such flags are not needed, but there are
situations with the complexity of real-world hardware where such flags
were really appreciated.
I came across a similar situation where a flag like combine_completed or
split1_completed or ira_in_progress would have been very handy, see
http://gcc.gnu.org/ml/gcc/2011-07/msg00146.html
http://gcc.gnu.org/ml/gcc/2011-07/msg00154.html
In that case I thought about something like
#include "tree-pass.h"
bool
avr_gate_split1 (void)
{
if (current_pass->static_pass_number
< pass_match_asm_constraints.pass.static_pass_number)
return true;
return false;
}
What happened is that I did not use this. Instead, the code does not
use pass meta-information and produced sub-optimal code for that reason.
Johann
RE: [RFC] Unsolicited usage of VFP registers for Cortex-M4F
> -Original Message- > From: Ilija Kocho [mailto:ili...@siva.com.mk] > Sent: Tuesday, October 09, 2012 21:08 > To: Joey Ye > Cc: gcc@gcc.gnu.org; Terry Guo > Subject: Re: [RFC] Unsolicited usage of VFP registers for Cortex-M4F > > Hi Joey > > Thank you for explanations. Now I have some comments and additional > questions. Since now it will be a discussion rather than looking for > help, I am re-routing the discussion to GCC mailing list. For those > looking for the complete history, here is the context: > http://gcc.gnu.org/ml/gcc-help/2012-10/msg00055.html > > > On 09.10.2012 12:21, Joey Ye wrote: > > [snip] > > >> On 24.09.2012 12:30, Ilija Kocho wrote: > >>> Hi colleagues > >>> > >>> In a course of implementing lazy context switching I the following > >>> link come to me: > >>> > >>> > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0298a/DA > >>> FIFGGE.html > >>> > [snip] > >>> Therefore here are my questions: > >>> > >>> 1) Does GCC use VFP registers for holding data other than floating > >>> point values (unsolicited VFP usage)? > > It doesn't so far. Although GCC has no problem use FP for non-FP, the > cost > > model in ARM backend says using VFP isn't performing better than > otherwise. > > > > For Cortex-M4F this isn't the best approach. I worked out a patch to > tune > > the cost model for M4F together with an option to enable/disable it. > I'm > > hoping to submit it later this year and it should enable Cortex-M4F > to use > > VFP extensively for non-FP data when option enabled. > > > >>> If (1) is true: > >>> 1.1) What conditions, in addition to selecting -mfloat-abi=hard (or > >>> softfp) shall cause such behaviour. I would appreciate some test > case. > > When the patch is upstreamed, and given that -ffpreg-for-nonfpdata is > > provided, VFP will be used for non-FP data when ever register > pressure is > > high. > > > [snip] > >> 1.4) Can it be disabled? I found no such command line option for ARM > >> targets. > > The command line will be as -f[no-]fpreg-for-nonfpdata > > According to current GCC conventions shoulfn't it begin with "m" i.e. > -m[no]fpreg-for-nonfpdata ? My typo. Should be -m. > > >>> 2) Above quote states that -mfloat-abi=soft should be used for libs, > but > >>> ld refuses to link them with code produced with -mfloat-abi=hard > even if > >>> the libs do not use floating point operations. Is there a waay to > tweak this? > > The quote isn't accurate nowadays. More and more libraries are built > with > > hard. Also a mechanism called multilib enables you to pick soft or > hard > > automatically according to linker command line > > Although I am not GCC expert I am aware of multilibs. Indeed, I have > succeeded in building of GCC with a pretty rich multilib collection. > > But my point is: at present, due to floating point ABI incompatibility, > we can't link functions/libs compiled with -mfloat-abi=soft flag to > functions/libs compiled with -mfloat-abi=hard flag, regardless whether > floating point is effectively in use or not. > But, won't particular functions, that _do not_ use floating point, > effectively have same ABI regardless of flags used (-mfloat-abi=soft or > -mfloat-abi=hard)? Then shouldn't it be possible to link them to both > /soft/ and /hard/ float-abi code? Then linker need to detect if there is really _no_ FP usage in a /hard/ copy, which is difficult if not impossible. The whole idea of different float ABI is to avoid such kind of check or the quiet runtime error without appropriate check. No matter what motivation behinds, I won't try to interlink soft and hard from maintain-ability and stability point of view. > > Any comments? > > Ilija >
Re: [RFC] Unsolicited usage of VFP registers for Cortex-M4F
On 10.10.2012 06:05, Joey Ye wrote: > >> -Original Message- >> From: Ilija Kocho [mailto:ili...@siva.com.mk] >> Sent: Tuesday, October 09, 2012 21:08 >> To: Joey Ye >> Cc: gcc@gcc.gnu.org; Terry Guo >> Subject: Re: [RFC] Unsolicited usage of VFP registers for Cortex-M4F >> >> Hi Joey >> >> Thank you for explanations. Now I have some comments and additional >> questions. Since now it will be a discussion rather than looking for >> help, I am re-routing the discussion to GCC mailing list. For those >> looking for the complete history, here is the context: >> http://gcc.gnu.org/ml/gcc-help/2012-10/msg00055.html >> >> >> On 09.10.2012 12:21, Joey Ye wrote: >> >> [snip] >> On 24.09.2012 12:30, Ilija Kocho wrote: > Hi colleagues > > In a course of implementing lazy context switching I the following > link come to me: > > >> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0298a/DA > FIFGGE.html > >> [snip] > Therefore here are my questions: > > 1) Does GCC use VFP registers for holding data other than floating > point values (unsolicited VFP usage)? >>> It doesn't so far. Although GCC has no problem use FP for non-FP, the >> cost >>> model in ARM backend says using VFP isn't performing better than >> otherwise. >>> For Cortex-M4F this isn't the best approach. I worked out a patch to >> tune >>> the cost model for M4F together with an option to enable/disable it. >> I'm >>> hoping to submit it later this year and it should enable Cortex-M4F >> to use >>> VFP extensively for non-FP data when option enabled. >>> > If (1) is true: > 1.1) What conditions, in addition to selecting -mfloat-abi=hard (or > softfp) shall cause such behaviour. I would appreciate some test >> case. >>> When the patch is upstreamed, and given that -ffpreg-for-nonfpdata is >>> provided, VFP will be used for non-FP data when ever register >> pressure is >>> high. >>> >> [snip] 1.4) Can it be disabled? I found no such command line option for ARM targets. >>> The command line will be as -f[no-]fpreg-for-nonfpdata >> According to current GCC conventions shoulfn't it begin with "m" i.e. >> -m[no]fpreg-for-nonfpdata ? > My typo. Should be -m. > > 2) Above quote states that -mfloat-abi=soft should be used for libs, >> but > ld refuses to link them with code produced with -mfloat-abi=hard >> even if > the libs do not use floating point operations. Is there a waay to >> tweak this? >>> The quote isn't accurate nowadays. More and more libraries are built >> with >>> hard. Also a mechanism called multilib enables you to pick soft or >> hard >>> automatically according to linker command line >> Although I am not GCC expert I am aware of multilibs. Indeed, I have >> succeeded in building of GCC with a pretty rich multilib collection. >> >> But my point is: at present, due to floating point ABI incompatibility, >> we can't link functions/libs compiled with -mfloat-abi=soft flag to >> functions/libs compiled with -mfloat-abi=hard flag, regardless whether >> floating point is effectively in use or not. >> But, won't particular functions, that _do not_ use floating point, >> effectively have same ABI regardless of flags used (-mfloat-abi=soft or >> -mfloat-abi=hard)? Then shouldn't it be possible to link them to both >> /soft/ and /hard/ float-abi code? > Then linker need to detect if there is really _no_ FP usage in a /hard/ > copy, which is difficult if not impossible. I was looking for some kind of -force option that would allow the user to override the compiler/linker. But now since there is no unsolicited VFP usage, I can consider this as non-issue. And with option like -m[no]fpreg-for-nonfpdata it will be non issue in future too. Thank you Ilija
