Re: C++ Expression Template Benchmarks for GCC/Clang/Intel/PGI/MSVC
On Wed, Jun 20, 2012 at 12:47 AM, Walter Landry wrote: > Richard Guenther wrote: >> On Fri, Jun 15, 2012 at 12:54 AM, Walter Landry wrote: >>> Hello Everyone, >>> >>> I thought you might be interested in some C++ expression template >>> benchmarks I have done. >>> >>> http://www.wlandry.net/Projects/FTensor#Benchmarks >>> >>> I found that GCC optimized the expression template code better than >>> unrolling expressions by hand. In fact, GCC was far, far better at >>> optimizing code with expression templates than any other compiler. I >>> ran the same benchmarks back in 2003, and GCC has improved quite a lot >>> since then. >> >> Heh, yeah - quite possibly because I myself was working with a POOMA >> based CFD code during my PhD which made me start working on inproving >> GCC for expression template code ;) It is btw interesting to try to enable >> profile-feedback for the compilers - for some compilers you'll see that >> the profile-generating executables are so slow as to be unusable (as they >> seem to keep all calls of the expression templates). > > I got around to trying profile guided optimization. For GCC it did > not make much difference, but for Intel it made a huge improvement for > the expression template code. Of course, the training executable ran > 20 times slower. But that was better than the Open64 compiler which > was too slow for me to get results. That's good to hear - my experience with ICC (I think it was 9.x) was even worse, a slowdown of a factor of 1000 or so which made PGO impractical, too. Impractical PGO are usually a sign that PGO instrumentation is done before any inlining happens. > I have added a section on PGO. > > http://www.wlandry.net/Projects/FTensor#PGO > > I also added results from Open64 and Pathscale's ENZO. Thanks, Richard.
Re: C Metaprogramming
On Wed, Jun 20, 2012 at 8:21 AM, Daniel Santos wrote:
> Thanks for your response!
>
> On 06/19/2012 08:40 AM, Richard Guenther wrote:
>> On Tue, Jun 19, 2012 at 4:41 AM, Daniel Santos wrote:
>>> So before filing any feature request bugs, I figured I should bring my
>>> discussion here first, as I believe some enhancements to gcc can better
>>> enable this type of programming.
>> The question this boils down to is - what is a constant? The current
>> implementation is pretty clear (see builtins.c:fold_builtin_constant_p)
>> and excludes any addresses of entities (being functions or variables).
>> Which probably asks for a new builtin to verify this, not over-loading
>> __builtin_constant_p.
> To be honest, I haven't peeked at the gcc sources yet for fear I would
> want to get too involved! :) I'll look at this. And yes, it would
> certainly make sense to have a separate builtin for this.
>>
>>> First off, we need a mechanism to verify constness of a function pointer
>>> at build time and generate an error when the value is non-const, similar
>>> to the construct:
>>>
>>> #define BUILD_BUG_ON_NON_CONST(arg) \
>>> do { \
>>> extern void __value_non_constant(void) \
>>> __attribute__((error("value not constant"))); \
>>> if (!__builtin_constant_p(arg)) \
>>> __not_constant_error(); \
>>> } while (0)
>>>
>>> Second, it will be helpful to have a mechanism to generate a -Winline
>>> warning when a function call by pointer cannot be inlined. Obviously,
>>> this is impossible if you can't first determine that it's a const
>>> function pointer and resolve that to the actual function. I'm sorry to
>>> say that I don't have a suggestion for doing this other than some
>>> __builtin_isinlineable() type of function (that accepts a function
>>> pointer). Perhaps solving the above problem and assuring that, after
>>> this test for function pointer constness succeeds and the const function
>>> pointer can be resolved to an inline function, the compiler can just
>>> emit a warning as it would when a normal function call to an inline
>>> cannot be inlined. Here's an example:
>>>
>>> #include
>>> static inline int myfunc(int a) {
>>> return a + 42;
>>> }
>>>
>>> static inline void jack(int (*const fnptr)(int)) {
>>> /* macro from above, except working for function pointers */
>>> BUILD_BUG_ON_NON_CONST(fnptr);
>>>
>>> /* if the above test passes, any inability to inline myfunc should
>>> * produce a -Winline warning
>>> */
>> I think that would be essentially the same as declaring myfunc
>> with attribute always-inline. You'd get an error if the function pointer
>> turns into a direct call and is not inlined.
> I haven't tried this yet, but I will. However, I thought that
> always_inline just caused the function to be inlined at all optimization
> levels (including none). If not, then it's incorrectly documented.
Yes, that's true. Though there are no guarantees for indirectly called
always-inline functions, thus at -O0 there may be practically no inlining
for your case.
Richard.
> Thanks,
> Daniel
Avoiding subregs of PSImode when word_mode is HImode
I'm running into issues with the MSP430 and use of PSImode in packed structures. Here the native word size is HImode, but all general purpose registers are capable of holding and operating on PSImode (=20 bit) values. Due to instruction set limitations, on this architecture: (subreg:HI (reg:PSI 0)) is fine, but (subreg:HI (reg:PSI 2)) is inexpressible. The upper 4 bits can only be accessed with multiple shift instructions. CANNOT_CHANGE_MODE_CLASS doesn't provide the control to express this restriction on subregs. The only way I've found to tell gcc this is to hack validate_subreg to rule out non-zero offsets on PSImode. Is there a non-hack way to tell GCC about this limitation? More generally, is there a way to tell GCC not to try to decompose SImode operations into subregs even though word_mode is HImode? I've got HARD_REGNO_NREGS, HARD_REGNO_NREGS_HAS_PADDING, and REGMODE_NATURAL_SIZE set up as accurately as I can: #define MSP430_MODE_NREGS(MODE) \ (PSImode == (MODE)\ ? 1 \ : ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) / UNITS_PER_WORD)) #define HARD_REGNO_NREGS(REGNO, MODE) MSP430_MODE_NREGS(MODE) #define HARD_REGNO_MODE_OK(REGNO, MODE) 1 #define MODES_TIEABLE_P(MODE1, MODE2) \ ((PSImode != (MODE1) || PSImode == (MODE2)) \ && (PSImode != (MODE2) || 1 == MSP430_MODE_NREGS (MODE1))) #define HARD_REGNO_NREGS_HAS_PADDING(REGNO, MODE) (PSImode == (MODE)) #define HARD_REGNO_NREGS_WITH_PADDING(REGNO, MODE) (PSImode == (MODE) ? 2 : MSP430_MODE_NREGS(MODE)) #define REGMODE_NATURAL_SIZE(MODE) (PSImode == (MODE) ? 2*UNITS_PER_WORD : UNITS_PER_WORD) Thanks. Peter
GCC 4.5.4 Status Report (2012-06-20)
Status == Now that GCC 4.7.1 is released it is time to retire the GCC 4.5 branch with a last release - GCC 4.5.4. This gets us to the goal set during the GCC Gathering last year - have only two maintained release branches. There have not been very many changes on the GCC 4.5 branch since the GCC 4.5.3 release and branch quality should be all-good. Expect a release candidate at the beginning of next week and a final release a week after. Thus, if you have regression fixes pending that need backporting that gives you about half a week to do so (if you think the risk factor is low and the benefit worthwhile). Quality Data Priority # Change from Last Report --- --- P10 P2 114 + 5 P34 - 1 --- --- Total 118 + 4 Previous Report === http://gcc.gnu.org/ml/gcc/2011-04/msg00412.html
Re: Regarding GCC Optimization flags and a customized profiler
Parang Saraf writes: > Expected Solution: 1. If you can point me to resources where I can > find more in-depth information about the optimization flags. Just the source code, unfortunately. At least it's complete. Ian
ARM GCC 4.8 test suite
Hi,
maybe it makes sense to look at some test suite comments since now all non EABI
configurations have been removed (is this correct?).
The problem was pointed out here:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00950.html
Here are some samples of the test suite (4.8-20120617):
gcc/testsuite/g++.old-deja/g++.other/vaarg2.C:// { dg-options "-Wno-abi" {
target arm_eabi } }
gcc/testsuite/g++.dg/ext/visibility/arm1.C:// { dg-do compile { target
arm*-*-eabi* arm*-*-symbianelf* } }
gcc/testsuite/g++.dg/ext/visibility/arm2.C:// { dg-do compile { target
arm*-*-*eabi* arm*-*-symbianelf* } }
gcc/testsuite/g++.dg/ext/visibility/arm3.C:// { dg-do compile { target
arm*-*-*eabi* } }
gcc/testsuite/g++.dg/abi/arm_va_list.C:// { dg-require-effective-target
arm_eabi }
Does it make sense to replace all "arm*-*-eabi*", "arm*-*-*eabi*", and
"arm*-*-symbianelf*" combinations with "arm_eabi"?
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
