Re: Generate abs target assembly code with saturation behavior
On Sun, 30 Jun 2013, Shiva Chen wrote: > But how the target generate abs instruction if the target abs have > saturation behavior ? > We couldn't use abssi2 naming pattern and ss_abssi2 naming pattern > doesn't exist. If you want to use a saturating abs instruction for C code that exhibits undefined behavior in cases where the instruction saturates, you need to add support for ss_abssi2 patterns and teach the GIMPLE-to-RTL conversion to use such patterns as appropriate (in the absence of -fwrapv/-ftrapv, of course). -- Joseph S. Myers jos...@codesourcery.com
Variadic Template Specialization vis a vi the INCITS/ISO/IEC 14882-2011 standard
Prompted by a Stack Overflow article :-
http://stackoverflow.com/questions/17332749/vs2013-fails-with-variadic-template-specialization/
There seems to be anomalies between GCC 4.8.1's 0x11 implementation
and the standard.
It shows the code :-
template struct OpF;
template struct
OpF { };
int foo(int x) { return 0; }
OpF f;
Given the C++ Standard outlaws this code, see 14.1 paragraphs 11 and 15.
Note that GCC accepts the following code with either -std=gnu++11 or
-std=c++11, the latter should be strict to the standard. Also given
these paragraphs were in the draft C++ standard too.
On the other hand GCC 4.8.1 will not accept a simple trailing 'int'
parameter after a variadic template list.
template < typename TR, typename ... Ts, int i> TR tester(Ts...);
// error: parameter pack ‘Ts’ must be at the end of the template
parameter list
There seems to be quite an inconsistency even in an augmentation to
the standard.
On a personal note both these forms are syntactically correct but not
semantically by the standard, given that this is just a simple type
based pattern matching problem as far as I can see it would be nice to
have it within the language as it seems to fit naturally with
requirements.
Regards,
Aaron
Re: Variadic Template Specialization vis a vi the INCITS/ISO/IEC 14882-2011 standard
On 30 June 2013 18:17, Aaron Gray wrote: > Prompted by a Stack Overflow article :- > > > http://stackoverflow.com/questions/17332749/vs2013-fails-with-variadic-template-specialization/ > > There seems to be anomalies between GCC 4.8.1's 0x11 implementation > and the standard. Then please report it to Bugzilla, not this mailing list, thanks.
Re: Generate abs target assembly code with saturation behavior
Thank you for all your kindly help make the issue more clear. Currently, we would disable abssi2 pattern and the soft-fp could work correctly. Thanks all the explanation and assistance. I really appreciate it. 2013/6/30 Joseph S. Myers : > On Sun, 30 Jun 2013, Shiva Chen wrote: > >> But how the target generate abs instruction if the target abs have >> saturation behavior ? >> We couldn't use abssi2 naming pattern and ss_abssi2 naming pattern >> doesn't exist. > > If you want to use a saturating abs instruction for C code that exhibits > undefined behavior in cases where the instruction saturates, you need to > add support for ss_abssi2 patterns and teach the GIMPLE-to-RTL conversion > to use such patterns as appropriate (in the absence of -fwrapv/-ftrapv, of > course). > > -- > Joseph S. Myers > jos...@codesourcery.com
4.8.2 -Og vs. -O1
I tried -Og optimization on a recent svn snapshot of 4.8 and don't see much difference in the code compared to -O1. If anything, at least for one case, -Og is actually less debuggable than -O1, e.g., for a simple buffer selection like this: uint8_t* buffer; if (condx == true) buffer = buf1; // buf1 is a static external buffer else buffer = buf2; // buf2 is a static external buffer uint8_t foo = buffer[1]; With -O1 there is assembly code associated with each buffer assignment statement. But with -Og there is no code under the first buffer = buf1 with it all under the 2nd buffer = buf2. So, with -Og, when stepping through the code with condx true, it appears that the wrong line is executing since the first buffer = buf1 has no code and never occurs. Of course, the result is still correct and is actually maybe more efficient or at least equal to the -O1 code, but there is no improved debug experience in this case. In this case, the debug experience with -O1 is closer to -O0 than -Og is. Also with -Og, some variables are still optimized away like -O1 and higher, but unlike -O0 where all variables are, of course, visible with the debugger (gdb). -gene
Re: 4.8.2 -Og vs. -O1
Have you compared it to -Os? That seems to produce assembly closer to what you would likely write by hand. I haven't benchmarked it much but it gives 7-10% smaller code in general. In many cases, fewer instructions is also a performance win. Gene Smith wrote: I tried -Og optimization on a recent svn snapshot of 4.8 and don't see much difference in the code compared to -O1. If anything, at least for one case, -Og is actually less debuggable than -O1, e.g., for a simple buffer selection like this: uint8_t* buffer; if (condx == true) buffer = buf1; // buf1 is a static external buffer else buffer = buf2; // buf2 is a static external buffer uint8_t foo = buffer[1]; With -O1 there is assembly code associated with each buffer assignment statement. But with -Og there is no code under the first buffer = buf1 with it all under the 2nd buffer = buf2. So, with -Og, when stepping through the code with condx true, it appears that the wrong line is executing since the first buffer = buf1 has no code and never occurs. Of course, the result is still correct and is actually maybe more efficient or at least equal to the -O1 code, but there is no improved debug experience in this case. In this case, the debug experience with -O1 is closer to -O0 than -Og is. Also with -Og, some variables are still optimized away like -O1 and higher, but unlike -O0 where all variables are, of course, visible with the debugger (gdb). -gene
