Re: Towards GNU11
On Wed, Oct 08, 2014 at 08:39:40PM -0600, Jeff Law wrote: > I like it. And one could reasonably argue that now is the time to change > since that maximizes the time for folks to find broken code. Yep, this is definitely stage1 stuff. We still have a few weeks, but I wouldn't want to rush such a change in the nick of time. > I'd go so far as to conditionally approve -- if other maintainers don't > shout out in the next week or so against, then I feel this should go > forward. Thanks. I will wait at least until the end of next week. I'd like to hear from Joseph ;). > I know it's really early, but a "porting to ..." document ought to be > started and have something in it about these changes. Both how to fix the > broken code or how to go back to c89. Absolutely. I'll start something up once it's in. I feel that especially the inline semantics change should be addressed therein. Marek
RTL infrastructure leaks VALUE expressions into aliasing-detecting functions
Hello!
I'd like to bring PR 63475 to the attention of RTL maintainers. The
problem in the referred PR exposed the RTL infrastructure problem,
where VALUE expressions are leaked instead of MEM expresions into
various parts of aliasing-detecting support functions.
As an example, please consider following patch for base_alias_check:
--cut here--
Index: alias.c
===
--- alias.c (revision 216025)
+++ alias.c (working copy)
@@ -1824,6 +1824,13 @@ base_alias_check (rtx x, rtx x_base, rtx y, rtx y_
if (rtx_equal_p (x_base, y_base))
return 1;
+ if (GET_CODE (x) == VALUE || GET_CODE (y) == VALUE)
+{
+ debug_rtx (x);
+ debug_rtx (y);
+ gcc_unreachable ();
+}
+
/* The base addresses are different expressions. If they are not accessed
via AND, there is no conflict. We can bring knowledge of object
alignment into play here. For example, on alpha, "char a, b;" can
--cut here--
The crosscompiler to alpha-linux-gnu dies immediately on the testcase,
provided in the PR.
One of the checks that trigger this condition in base_alias_check is:
(and:DI (lo_sum:DI (reg/f:DI 13 $13 [72])
(symbol_ref:DI ("aaa") [flags 0x6] ))
(const_int -8 [0xfff8]))
with
(value:DI 7:3304360 @0x1b619ee0/0x1b614cb0)
and this is the reason why aliasing of aaa and bbb is not detected.
The (VALUE) RTX corresponds to:
cselib value 7:3304360 0x8a84cb0 (and:DI (lo_sum:DI (reg/f:DI 11 $11 [78])
(symbol_ref:DI ("bbb") [flags 0x6] ))
(const_int -8 [0xfff8]))
so, there is no way for current code to detect aliasing between these two RTXes.
Re: Towards GNU11
Am 08.10.2014 um 09:16 schrieb Richard Biener: > On Tue, 7 Oct 2014, Marek Polacek wrote: > I think it makes sense to do this (and I expect C++ will follow > with defaulting to -std=c++11 once the ABI stuff has settled). > > Of course it would be nice to look at the actual fallout in > a whole-distribution rebuild... I can certainly do that, once stage1 is finished, hopefully for more than x86 architectures. What happened to the plans to stabilize the libstdc++ c++11 ABI? Is this still a target for GCC 5? Matthias
Re: Towards GNU11
On 10/09/2014 08:45 AM, Matthias Klose wrote: What happened to the plans to stabilize the libstdc++ c++11 ABI? Is this still a target for GCC 5? Yes. Jason
Re: Towards GNU11
On Thu, 9 Oct 2014, Marek Polacek wrote: > On Wed, Oct 08, 2014 at 08:39:40PM -0600, Jeff Law wrote: > > I like it. And one could reasonably argue that now is the time to change > > since that maximizes the time for folks to find broken code. > > Yep, this is definitely stage1 stuff. We still have a few weeks, but > I wouldn't want to rush such a change in the nick of time. > > > I'd go so far as to conditionally approve -- if other maintainers don't > > shout out in the next week or so against, then I feel this should go > > forward. > > Thanks. I will wait at least until the end of next week. > > I'd like to hear from Joseph ;). I approve of the change in default (I just don't think it's a change to make on my say-so alone). -- Joseph S. Myers jos...@codesourcery.com
fast-math optimization question
I have a -ffast-math (missing?) optimization question. I noticed on MIPS
that if I compiled:
#include
extern x;
void foo() { x = sin(log(x)); }
GCC will extend 'x' to double precision, call the double precision log and sin
functions and then truncate the result to single precision.
If instead, I have:
#include
extern x;
void foo() { x = log(x); x = sin(x); }
Then GCC will call the single precision log and sin functions and not do
any extensions or truncations. In addition to avoiding the extend/trunc
instructions the single precision log and sin functions are presumably
faster then the double precision ones making the entire code much faster.
Is there a reason why GCC couldn't (under -ffast-math) call the single
precision routines for the first case?
Steve Ellcey
sell...@mips.com
Re: fast-math optimization question
On Thu, Oct 9, 2014 at 11:23 AM, Steve Ellcey wrote:
> I have a -ffast-math (missing?) optimization question. I noticed on MIPS
> that if I compiled:
>
> #include
> extern x;
> void foo() { x = sin(log(x)); }
>
> GCC will extend 'x' to double precision, call the double precision log and sin
> functions and then truncate the result to single precision.
>
> If instead, I have:
>
> #include
> extern x;
> void foo() { x = log(x); x = sin(x); }
>
> Then GCC will call the single precision log and sin functions and not do
> any extensions or truncations. In addition to avoiding the extend/trunc
> instructions the single precision log and sin functions are presumably
> faster then the double precision ones making the entire code much faster.
>
> Is there a reason why GCC couldn't (under -ffast-math) call the single
> precision routines for the first case?
There is no reason why it could not. The reason why it does not
currently is because there is no pass which does the demotion and the
only case of demotion that happens is with a simple
(float)function((double)float_val);
Thanks,
Andrew
Re: fast-math optimization question
On Thu, 2014-10-09 at 11:27 -0700, Andrew Pinski wrote: > > Is there a reason why GCC couldn't (under -ffast-math) call the single > > precision routines for the first case? > > There is no reason why it could not. The reason why it does not > currently is because there is no pass which does the demotion and the > only case of demotion that happens is with a simple > (float)function((double)float_val); > > Thanks, > Andrew Do you know which pass does the simple '(float)function((double)float_val)' demotion? Maybe that would be a good place to extend things. Steve Ellcey
Re: fast-math optimization question
On Thu, Oct 9, 2014 at 11:32 AM, Steve Ellcey wrote: > On Thu, 2014-10-09 at 11:27 -0700, Andrew Pinski wrote: > >> > Is there a reason why GCC couldn't (under -ffast-math) call the single >> > precision routines for the first case? >> >> There is no reason why it could not. The reason why it does not >> currently is because there is no pass which does the demotion and the >> only case of demotion that happens is with a simple >> (float)function((double)float_val); >> >> Thanks, >> Andrew > > Do you know which pass does the simple > '(float)function((double)float_val)' demotion? Maybe that would be a > good place to extend things. Yes builtins.c. > > Steve Ellcey >
GCC 4.9 generates bigger code for x86
Hi all, I just noticed that 4.9 generates some code overhead for 386 machines respect to 4.8. In my test case I used 4.8.1 and 4.9.1 and realized that when compiling with "-Os -fno-exceptions -fno-align-functions -fomit-frame-pointer" certain things change: On 4.9 the backend adds some "nop" after ret or jmp. It also stops using "leave" instruction, which is really convenient to save some instructions. It think it is not using leave because of register allocation. In 4.8 a function starts like this: 390:55 push %ebp 391:89 e5mov%esp,%ebp 393:53 push %ebx Whereas in 4.9 it starts: 386:53 push %ebx 387:89 cbmov%ecx,%ebx 389:83 ec 28 sub$0x28,%esp So the first function actually saves some space. Any ideas, thoughts, comments? Thanks a lot, David G.F.
Re: fast-math optimization question
On October 9, 2014 8:40:49 PM CEST, Andrew Pinski wrote: >On Thu, Oct 9, 2014 at 11:32 AM, Steve Ellcey wrote: >> On Thu, 2014-10-09 at 11:27 -0700, Andrew Pinski wrote: >> >>> > Is there a reason why GCC couldn't (under -ffast-math) call the >single >>> > precision routines for the first case? >>> >>> There is no reason why it could not. The reason why it does not >>> currently is because there is no pass which does the demotion and >the >>> only case of demotion that happens is with a simple >>> (float)function((double)float_val); >>> >>> Thanks, >>> Andrew >> >> Do you know which pass does the simple >> '(float)function((double)float_val)' demotion? Maybe that would be a >> good place to extend things. > >Yes builtins.c. I think it is in convert.c. but both are not passes really. Richard. >> >> Steve Ellcey >>
Re: fast-math optimization question
On Thu, 9 Oct 2014, Steve Ellcey wrote: > Do you know which pass does the simple > '(float)function((double)float_val)' demotion? Maybe that would be a > good place to extend things. convert.c does such transformations. Maybe the transformations in there could move to the match-and-simplify infrastructure - convert.c is not a particularly good place for optimization, and having similar transformations scattered around (fold-const, convert.c, front ends, SSA optimizers) isn't helpful; hopefully match-and-simplify will allow some unification of this sort of optimization. -- Joseph S. Myers jos...@codesourcery.com
Re: Towards GNU11
On Oct 7, 2014, at 2:07 PM, Marek Polacek wrote: > I'd like to kick off a discussion about moving the default standard > for C from gnu89 to gnu11. I endorse the change of default. > The things I had to fix in the testsuite nicely reflect what we can expect > in the real life: A wiki page that has the types of changes people hit in real code with how to fix it, would be useful, helpful. Might be nice to have this in the document, but, don’t know if people want to do that much work. The wiki site is nice, as if others do world builds, then can add what ever they hit in easily, which then makes that even more complete. This is a nice to have, I don’t think the work going in should be gated on this. > Comments? Two comment: Thank you for all your hard work. Yes please.
gcc-4.8-20141009 is now available
Snapshot gcc-4.8-20141009 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20141009/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 216050 You'll find: gcc-4.8-20141009.tar.bz2 Complete GCC MD5=99c8c52e1b5bfb6d130a6b63d02d866c SHA1=9d48c4d21eeb7d275bed2c794803256ccde841bb Diffs from 4.8-20141002 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: fast-math optimization question
On Thu, 2014-10-09 at 19:50 +, Joseph S. Myers wrote: > On Thu, 9 Oct 2014, Steve Ellcey wrote: > > > Do you know which pass does the simple > > '(float)function((double)float_val)' demotion? Maybe that would be a > > good place to extend things. > > convert.c does such transformations. Maybe the transformations in there > could move to the match-and-simplify infrastructure - convert.c is not a > particularly good place for optimization, and having similar > transformations scattered around (fold-const, convert.c, front ends, SSA > optimizers) isn't helpful; hopefully match-and-simplify will allow some > unification of this sort of optimization. I did a quick and dirty experiment with the match-and-simplify branch just to get an idea of what it might be like. The branch built for MIPS right out of the box so that was great and I added a couple of rules (see below) just to see if it would trigger the optimization I wanted and it did. I was impressed with the match-and-simplify infrastructure, it seemed to work quite well. Will this branch be included in GCC 5.0? Steve Ellcey sell...@mips.com Code added to match-builtin.pd: (if (flag_unsafe_math_optimizations) /* Optimize "(float) expN(x)" [where x is type double] to "expNf((float) x)", i.e. call the 'f' single precision func */ (simplify (convert (BUILT_IN_LOG @0)) (if ((TYPE_MODE (type) == SFmode) && (TYPE_MODE (TREE_TYPE (@0)) == DFmode)) (BUILT_IN_LOGF (convert @0 ) (if (flag_unsafe_math_optimizations) /* Optimize "(float) expN(x)" [where x is type double] to "expNf((float) x)", i.e. call the 'f' single precision func */ (simplify (convert (BUILT_IN_SIN @0)) (if ((TYPE_MODE (type) == SFmode) && (TYPE_MODE (TREE_TYPE (@0)) == DFmode)) (BUILT_IN_SINF (convert @0 )
