From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: richard.earnshaw AT arm.com Cc: Mark Mitchell , rms AT gnu.org, jbuck AT synopsys.com, mrs AT wrs.com, gcc AT gcc.gnu.org Subject: Re: type based aliasing again Date: Wed, 15 Sep 1999 02:05:00 -0000 Message-id: <2859.937221516@upchuck.cygnus.com> References: <199909131102.MAA25960@sun52.NIS.cambridge> X-SW-Source: 1999-09/msg00602.html In message < 199909131102.MAA25960@sun52.NIS.cambridge >you write: > > mark@codesourcery.com said: > > I think that making -fno-strict-aliasing the default is sensible > > proposal, and worth debating. > > > It is the default at -O1 or less. I would be inclined to argue that this > should be adequate for "legacy" code and that the higher levels of > optimization should be allowed to fully exploit the provisions of the C > standard (this is not to suggest that a warning shouldn't be generated if > possible). Good point. > We are somewhat constrained by our relatively limited number of > optimization levels (0, 1, 2, 3, s); I guess extending the range is hard, > mainly because of a user-education issue. But it would be useful if we > could have a level above which we say that we assume that code fully > conforms to the C (or other relevant) standard. We really need to make some space in the -O namespace. So we shouldn't let that problem stop us if people think it's a reasonable thing to do. Right now -O3 is just -O2 + -finline-functions. I've got no objection to moving -finline-functions to some higher -O level to give us some room to add optimizations which may depend on strict adherence of code to the ANSI/ISO standards or which may take more memory/time (load/store motion would be a good example). Yes there's a user education issue, but it's a hell of a lot smaller than the "how to write conforming code" education issue. jeff From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: richard.earnshaw@arm.com Cc: Mark Mitchell , rms@gnu.org, jbuck@synopsys.com, mrs@wrs.com, gcc@gcc.gnu.org Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <2859.937221516@upchuck.cygnus.com> References: <199909131102.MAA25960@sun52.NIS.cambridge> X-SW-Source: 1999-09n/msg00602.html Message-ID: <19990930180200.cjDX-_7ZPsmbzOmH7zS8dntTN_ouJynXhfbl9g6oGkk@z> In message < 199909131102.MAA25960@sun52.NIS.cambridge >you write: > > mark@codesourcery.com said: > > I think that making -fno-strict-aliasing the default is sensible > > proposal, and worth debating. > > > It is the default at -O1 or less. I would be inclined to argue that this > should be adequate for "legacy" code and that the higher levels of > optimization should be allowed to fully exploit the provisions of the C > standard (this is not to suggest that a warning shouldn't be generated if > possible). Good point. > We are somewhat constrained by our relatively limited number of > optimization levels (0, 1, 2, 3, s); I guess extending the range is hard, > mainly because of a user-education issue. But it would be useful if we > could have a level above which we say that we assume that code fully > conforms to the C (or other relevant) standard. We really need to make some space in the -O namespace. So we shouldn't let that problem stop us if people think it's a reasonable thing to do. Right now -O3 is just -O2 + -finline-functions. I've got no objection to moving -finline-functions to some higher -O level to give us some room to add optimizations which may depend on strict adherence of code to the ANSI/ISO standards or which may take more memory/time (load/store motion would be a good example). Yes there's a user education issue, but it's a hell of a lot smaller than the "how to write conforming code" education issue. jeff