Re: [PATCH 1/3] colorize: use isatty module
On 01/03/2012 09:48 AM, Jim Meyering wrote: Paolo Bonzini wrote: * bootstrap.conf: Add isatty module. * gnulib: Update to latest. * lib/colorize.h: Remove argument from should_colorize. * lib/ms/colorize.h: Likewise. * lib/colorize-impl.c: Factor isatty call out of here... * lib/ms/colorize-impl.c: ... and here... * src/main.c: ... into here. Hi Paolo, At least with gcc-4.7.0 20120102, a warning-enabled build now fails like this: colorize.c: In function 'init_colorize': colorize.c:37:6: error: function might be candidate for attribute 'const' [-Werror=suggest-attribute=const] cc1: all warnings being treated as errors Thanks, my GCC is indeed older. Perhaps GCC should be changed to avoid the warning on functions returning void. If a void function can be const, it pretty much has to be empty, and so it is quite likely a placeholder for something that is not const. Paolo
Re: [PATCH 1/3] colorize: use isatty module
Paolo Bonzini wrote: > On 01/03/2012 09:48 AM, Jim Meyering wrote: >> Paolo Bonzini wrote: >> >>> * bootstrap.conf: Add isatty module. >>> * gnulib: Update to latest. >>> * lib/colorize.h: Remove argument from should_colorize. >>> * lib/ms/colorize.h: Likewise. >>> * lib/colorize-impl.c: Factor isatty call out of here... >>> * lib/ms/colorize-impl.c: ... and here... >>> * src/main.c: ... into here. >> >> Hi Paolo, >> At least with gcc-4.7.0 20120102, a warning-enabled build now fails like >> this: >> >>colorize.c: In function 'init_colorize': >>colorize.c:37:6: error: function might be candidate for attribute >> const' [-Werror=suggest-attribute=const] >>cc1: all warnings being treated as errors > > Thanks, my GCC is indeed older. > > Perhaps GCC should be changed to avoid the warning on functions > returning void. If a void function can be const, it pretty much has > to be empty, and so it is quite likely a placeholder for something > that is not const. To address grep's immediate problem -- I require use of --enable-gcc-warnings and want to continue using the newer gcc -- I have applied this: >From 082f0d1a771a2febcc14ffce13f44ed7c4553ad4 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 3 Jan 2012 10:25:37 +0100 Subject: [PATCH] build: avoid build failure with --enable-gcc-warnings and recent gcc * lib/colorize-posix.c: Disable -Wsuggest-attribute=const, to avoid warning about this empty init_colorize function. --- lib/colorize-posix.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/lib/colorize-posix.c b/lib/colorize-posix.c index 37bc640..116bbb2 100644 --- a/lib/colorize-posix.c +++ b/lib/colorize-posix.c @@ -16,6 +16,12 @@ Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA 02110-1301, USA. */ +/* Without this pragma, gcc 4.7.0 20120102 suggests that the + init_colorize function might be candidate for attribute 'const' */ +#if (__GNUC__ == 4 && 6 <= __GNUC_MINOR__) || 4 < __GNUC__ +# pragma GCC diagnostic ignored "-Wsuggest-attribute=const" +#endif + #include #include "colorize.h" -- 1.7.8.1.391.g2c2ad
RE: [RFC, ARM] cortex_a8_call cost
Hi Dmitry, Sorry about the late reply - been on vacation and catching up today on email. Here's why I'm asking. In the following example, dependence cost of 32 for cortex_a8_call causes insns 464 and 575 to be separated by 308 (in spite having same priority), because 575 is not ready at tick 12, which causes generation of separate IT-blocks for them on Thumb-2. ;;<> 9--> 300 r0=call [`spec_putc']:cortex_a8_issue_branch ;;<> 9--> 306 r3=sl 0>>0x18^r8 :cortex_a8_default ;;<> 10--> 309 cc=cmp(r5,r8) :cortex_a8_default ;;<> 11--> 307 r3=[r3*0x4+r9] :cortex_a8_load_store_1 ;;<> 12--> 464 (cc) r2=0x1 :cortex_a8_default ;;<> 13--> 308 sl=sl<<0x8^r3 :cortex_a8_default ;;<> 41--> 575 (cc) [sp+0x4]=r2 :cortex_a8_load_store_1 Insn 575 has true dependency with call insn 300 on r2, which is CALL_USED_REG, and as 464 is conditional, 575 retains true dependency with 300. Setting cortex_a8_call cost to 1 saves 186 bytes on SPEC2000 INT (but I'm not sure whether it's only because of less IT-block splitting). I doubt that the size savings you are seeing are just because of lesser IT block splitting. If you measured the number of spills my suspicion is that you'd be seeing fewer spills because of this change and any change you see in IT block splitting is a consequence of that. For the A8 this should be OK - try a few benchmarks to be sure it doesn't spring any surprises performance wise. cheers Ramana --- Ramana Radhakrishnan PDSW Tools ARM Ltd.
Re: RFC: Handle conditional expression in sccvn/fre/pre
On Mon, Jan 2, 2012 at 10:54 PM, Richard Guenther wrote: > Yes. It won't handle > > if (x > 1) > ... > tem = x > 1; > > or > > if (x > 1) > ... > if (x > 1) > > though maybe we could teach PRE to do the insertion by properly > putting x > 1 into EXP_GEN in compute_avail (but not into AVAIL_OUT). > Not sure about this though. Currently we don't do anything to > GIMPLE_COND operands (which seems odd anyway, we should > at least add the operands to EXP_GEN). I did an experiment which shows by setting cond_expr in EXP_GEN properly, PRE could insert expression in following case: //necessary declaration of variable a/b/g int tmp; if (x_cond) tmp = a > 2; else tmp = b; if (a > 2) g = tmp; But the problem you mention : "PRE separates conditional expression and jump to far" still exists in this kind of cases. Now I doubt the benefit to make PRE handle cond_expr, because in back end, machines normally have only one flag to store the result. And for other cases like: if (a > 2) ... if (a > 2) Current logic of insertion(in do_regular_insertion) simply won't insert expression before the first GIMPLE_COND statement, because it only considers basic blocks have multiple predecessors and the expression are partial redundant. Anyway I think this can be done by implementing new insertion strategy for GIMPLE_COND. -- Best Regards.
new mailing list language-experts
For discussions around programming languages, within GNU, but not specific to a particular GNU package, there is now a mailing list . The subscription page is here: https://lists.gnu.org/mailman/listinfo/language-experts You are invited to join if you have extensive experience in this area. Topics will range from programming language design issues to implementation techniques. Possible topics include specific language features, diagnostics, multi-threading / parallel execution, programming styles, just-in-time compilation, and security. Bruno
GCC/GLIBC and non-temporal instructions
I have multi-threaded C++ application that relies on fine-grain parallelism and makes extensive use of interlocked instructions and memory barriers for inter-thread synchronization and communication. I currently use LFENCE/SFENCE/MFENCE instructions for memory barriers (on processors that have these instructions, otherwise resorting to LOCK-OR). I was looking to relax barriers from LFENCE/SFENCE/MFENCE to LOCK-OR/no-op/LOCK-OR correspondingly -- assuming I am able to verify that no non-temporal SSE/3DNow instructions are used by the compiler-generated code or runtime library without proper bracketing such instructions with memory fences. The reasons for desired relaxation is that: 1) LOCK-OR is believed to take less cycles than xFENCE instructions (though I have not actually benchmarked them yet, but this appears to be a common belief); 2) even more importantly, since memory barriers are most usually coupled with interlocked instructions that access data entities used for inter-thread synchronization anyway, it would be beneficial to eliminate extra memory barrier in such places as redundant on x86/x64, because memory barrier is already provided by interlocked instruction operating on primary datum, and therefore extra xFENCE is redundant -- except only for the possibility of unbracketed non-temporal instructions in CPU instruction stream. The issue is significant since application can make thousands inter-thread transactions per second. The question is whether there is any GCC/runtime policy on non-temporal SSE/3DNow instructions? Specifically, can application expect that: 1) Compiler-generated code will not contain non-temporal instructions blocks not bracketed by xFENCE on both sides? 2) Normal application code that may engage in inter-thread communication won't be embedded inside such blocks? 3) Run-time library won't use non-temporal instructions blocks not bracketed by xFENCE on both sides? Or is it a completely gray area?
Re: GCC/GLIBC and non-temporal instructions
Sergey Oboguev writes: > The question is whether there is any GCC/runtime policy on non-temporal > SSE/3DNow instructions? As far as I know gcc will never generate any non-temporal instructions, except if the programmer uses the special intrinsic functions which generate them. If the programmer uses those intrinsic functions, she or he is entirely responsible for issuing the required fence instructions, via intrinsic functions like _mm_lfence. So the GCC/runtime policy on non-temporal instructions is that using them correctly is entirely up to the programmer. Ian
Re: GCC/GLIBC and non-temporal instructions
Well, all these storent emit_storent_insn may_use_storent_in_loop storent_optab nontemporal assign_set_nontemporal_move mark_nontemporal_store mark_nontemporal_stores nontemporal_store_p schedule_prefetches should_issue_prefetch issue_prefetch_ref etc. things in GCC sources -- do they ever get triggered or not? Also, looking up in GLIBC sources I can see MOVNTxxx instructions terminated with SFENCE, but not prefixed with LFENCE. What could this possibly mean? - Sergey - Original Message From: Ian Lance Taylor To: Sergey Oboguev Cc: gcc@gcc.gnu.org Sent: Tue, January 3, 2012 11:24:15 AM Subject: Re: GCC/GLIBC and non-temporal instructions Sergey Oboguev writes: > The question is whether there is any GCC/runtime policy on non-temporal > SSE/3DNow instructions? As far as I know gcc will never generate any non-temporal instructions, except if the programmer uses the special intrinsic functions which generate them. If the programmer uses those intrinsic functions, she or he is entirely responsible for issuing the required fence instructions, via intrinsic functions like _mm_lfence. So the GCC/runtime policy on non-temporal instructions is that using them correctly is entirely up to the programmer. Ian
Re: GCC/GLIBC and non-temporal instructions
Sergey Oboguev writes: > Well, all these > > storent > emit_storent_insn > may_use_storent_in_loop > storent_optab > nontemporal > assign_set_nontemporal_move > mark_nontemporal_store > mark_nontemporal_stores > nontemporal_store_p > schedule_prefetches > should_issue_prefetch > issue_prefetch_ref > etc. > > things in GCC sources -- do they ever get triggered or not? Ah, you're quite right, I was not aware of that. The rule there appears to be the compiler will issue an mfence if it decides to use any non-temporal moves in a loop. However, I don't see anything in the code which will avoid using non-temporal moves, or a fence, if there are existing non-temporal moves (via instrinsic functions) in the loop. This seems like it is at least a documentation bug. > Also, looking up in GLIBC sources I can see MOVNTxxx instructions terminated > with SFENCE, but not prefixed with LFENCE. What could this possibly mean? You would have to ask the glibc maintainers about that. I don't know enough to speculate. Ian
Re: GCC/GLIBC and non-temporal instructions
Well, it would help if someone who knows what this code does (and does not), ideally its authors, could clarify definitively. Also, what happens if application performs inter-thread communication inside the loop? - Sergey - Original Message From: Ian Lance Taylor To: Sergey Oboguev Cc: gcc@gcc.gnu.org Sent: Tue, January 3, 2012 12:08:22 PM Subject: Re: GCC/GLIBC and non-temporal instructions Sergey Oboguev writes: > Well, all these > > storent > emit_storent_insn > may_use_storent_in_loop > storent_optab > nontemporal > assign_set_nontemporal_move > mark_nontemporal_store > mark_nontemporal_stores > nontemporal_store_p > schedule_prefetches > should_issue_prefetch > issue_prefetch_ref > etc. > > things in GCC sources -- do they ever get triggered or not? Ah, you're quite right, I was not aware of that. The rule there appears to be the compiler will issue an mfence if it decides to use any non-temporal moves in a loop. However, I don't see anything in the code which will avoid using non-temporal moves, or a fence, if there are existing non-temporal moves (via instrinsic functions) in the loop. This seems like it is at least a documentation bug. > Also, looking up in GLIBC sources I can see MOVNTxxx instructions terminated > with SFENCE, but not prefixed with LFENCE. What could this possibly mean? You would have to ask the glibc maintainers about that. I don't know enough to speculate. Ian
