Re: Proposal to deprecate: mep (Toshiba Media Processor)
> Given a combination of "I have new responsibilities" and "nothing has > happened with mep for a long time" I would like to step down as mep > maintainer. > > If someone would like to pick up maintainership of this target, please > contact me and/or the steering committee. Otherwise, I propose this > target be deprecated in GCC 6 and removed in 7. MeP is now deprecated.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 03/01/2016 11:43 AM, Michael Matz wrote: Hi, On Mon, 29 Feb 2016, Jason Merrill wrote: Also this insistence that all of "trivially copyable" is already quite nicely specified in the C++ ABI is still not really relevant because C++ _is not the only language out there_. I'm not sure how often I have to repeat this until people get it. Other language ABIs can handle language specific calling conventions as appropriate for them. The psABI can only talk about things that are in its domain. Naturally. How far to follow that road, though? Remove the word "class" from the description of empty types again? Why is that in-domain and the notion of trivially copyable isn't? Yes, dropping "class" seems appropriate, especially since the psABI uses that word to refer to register classes. Jason
gcc-5-20160301 is now available
Snapshot gcc-5-20160301 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20160301/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 233867 You'll find: gcc-5-20160301.tar.bz2 Complete GCC MD5=daf539f7cacd3c673ea0de83062fa72f SHA1=85eb6d0678c8c54932f3bb9a3e55b28b9cf5aa12 Diffs from 5-20160223 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 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: Importance of transformations that turn data dependencies into control dependencies?
On Tue, Mar 01, 2016 at 05:55:07PM +0100, Michael Matz wrote: > Hi, > > On Tue, 1 Mar 2016, Richard Biener wrote: > > > > What about the example I gave above? Is it unrealistic for compilers > > > do ever do something like this, or is it just unlikely to gain much > > > performance, or is it just that GCC does not do this today? > > > > GCC does not do this today with the exception of value-profiling. GCC > > in other cases does not establish equivalences but only relations (a < > > b, etc.) that are not a problem as far as I can see because those do not > > allow to change expressions using a to use b. > > Made up example using relations: > > int32 a, b; > a = (b >> 31) & 1; > > --> > > if (b < 0) > a = 1; > else > a = 0; > > data-dep to control-dep and only relations :) (I think this is taken care > of by Pauls wording, ignoring the fact that these aren't pointers anyway > and hence don't carry a dependency through them, only onto them at max) Agreed, these are not pointers, and therefore do not carry dependencies. Thanx, Paul
Re: Importance of transformations that turn data dependencies into control dependencies?
Hi, On Tue, 1 Mar 2016, Richard Biener wrote: > > What about the example I gave above? Is it unrealistic for compilers > > do ever do something like this, or is it just unlikely to gain much > > performance, or is it just that GCC does not do this today? > > GCC does not do this today with the exception of value-profiling. GCC > in other cases does not establish equivalences but only relations (a < > b, etc.) that are not a problem as far as I can see because those do not > allow to change expressions using a to use b. Made up example using relations: int32 a, b; a = (b >> 31) & 1; --> if (b < 0) a = 1; else a = 0; data-dep to control-dep and only relations :) (I think this is taken care of by Pauls wording, ignoring the fact that these aren't pointers anyway and hence don't carry a dependency through them, only onto them at max) Ciao, Michael.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
Hi, On Mon, 29 Feb 2016, Jason Merrill wrote: > > Also this insistence that all of "trivially copyable" is already quite > > nicely specified in the C++ ABI is still not really relevant because > > C++ _is not the only language out there_. I'm not sure how often I > > have to repeat this until people get it. > > Other language ABIs can handle language specific calling conventions as > appropriate for them. The psABI can only talk about things that are in > its domain. Naturally. How far to follow that road, though? Remove the word "class" from the description of empty types again? Why is that in-domain and the notion of trivially copyable isn't? Ciao, Michael.
Re: Importance of transformations that turn data dependencies into control dependencies?
On Fri, Feb 26, 2016 at 8:10 PM, Torvald Riegel wrote:
> On Fri, 2016-02-26 at 11:49 +0100, Richard Biener wrote:
>> On Thu, Feb 25, 2016 at 6:33 PM, Torvald Riegel wrote:
>> > On Wed, 2016-02-24 at 13:14 +0100, Richard Biener wrote:
>> >> On Tue, Feb 23, 2016 at 8:38 PM, Torvald Riegel
>> >> wrote:
>> >> > I'd like to know, based on the GCC experience, how important we consider
>> >> > optimizations that may turn data dependencies of pointers into control
>> >> > dependencies. I'm thinking about all optimizations or transformations
>> >> > that guess that a pointer might have a specific value, and then create
>> >> > (specialized) code that assumes this value that is only executed if the
>> >> > pointer actually has this value. For example:
>> >> >
>> >> > int d[2] = {23, compute_something()};
>> >> >
>> >> > int compute(int v) {
>> >> > if (likely(v == 23)) return 23;
>> >> > else ;
>> >> > }
>> >> >
>> >> > int bar() {
>> >> > int *p = ptr.load(memory_order_consume);
>> >> > size_t reveal_that_p_is_in_d = p - d[0];
>> >> > return compute(*p);
>> >> > }
>> >> >
>> >> > Could be transformed to (after inlining compute(), and specializing for
>> >> > the likely path):
>> >> >
>> >> > int bar() {
>> >> > int *p = ptr.load(memory_order_consume);
>> >> > if (p == d) return 23;
>> >> > else ;
>> >> > }
>> >>
>> >> Note that if a user writes
>> >>
>> >> if (p == d)
>> >>{
>> >> ... do lots of stuff via p ...
>> >>}
>> >>
>> >> GCC might rewrite accesses to p as accesses to d and thus expose
>> >> those opportunities. Is that a transform that isn't valid then or is
>> >> the code written by the user (establishing the equivalency) to blame?
>> >
>> > In the context of this memory_order_consume proposal, this transform
>> > would be valid because the program has already "reveiled" what value p
>> > has after the branch has been taken.
>> >
>> >> There's a PR where this kind of equivalencies lead to unexpected (wrong?)
>> >> points-to results for example.
>> >>
>> >> > Other potential examples that come to mind are de-virtualization, or
>> >> > feedback-directed optimizations that has observed at runtime that a
>> >> > certain pointer is likely to be always equal to some other pointer (eg.,
>> >> > if p is almost always d[0], and specializing for that).
>> >>
>> >> That's the cases that are quite important in practice.
>> >
>> > Could you quantify this somehow, even if it's a very rough estimate?
>> > I'm asking because it's significant and widely used, then this would
>> > require users or compiler implementors to make a difficult trade-off
>> > (ie, do you want mo_consume performance or performance through those
>> > other optimizations?).
>>
>> Probably resoved by your followup on how the transform is safe anyway.
>
> Are you saying this because de-virtualization would be the only
> optimization that matters for performance and turns data into control
> dependencies (but can be considered safe)?
>
> What about feedback-directed optimizations, for which you said it would
> be one of the important cases too? Will these only look equivalences in
> non-mutable data too (ie, like vtables)?
We do have other value-profiling transforms - for example divison/modulo
of a constant:
if (x == 256)
z = y / 256;
else
z = y / x;
> What about the example I gave above? Is it unrealistic for compilers do
> ever do something like this, or is it just unlikely to gain much
> performance, or is it just that GCC does not do this today?
GCC does not do this today with the exception of value-profiling. GCC in
other cases does not establish equivalences but only relations (a < b, etc.)
that are not a problem as far as I can see because those do not allow to
change expressions using a to use b.
>> >> > Also, it would be interesting to me to know how often we may turn data
>> >> > dependencies into control dependencies in cases where this doesn't
>> >> > affect performance significantly.
>> >>
>> >> I suppose we try to avoid that but can we ever know for sure? Like
>> >> speculative devirtualization does this (with the intent that it _does_
>> >> matter,
>> >> of course).
>> >>
>> >> I suppose establishing non-dependence isn't an issue, like with the
>> >> vectorizer adding runtime dependence checks and applying versioning
>> >> to get a vectorized and a not vectorized loop (in case there are
>> >> dependences)?
>> >
>> > I'm not sure I understand you correctly. Do you have a brief example,
>> > perhaps? For mo_consume and its data dependencies, if there might be a
>> > dependence, the compiler would have to preserve it; but I guess that
>> > both a vectorized loop an one that accessses each element separately
>> > would preserve dependences because it's doing those accesses, and they
>> > depend on the input data.
>> > OTOH, peraps HW vector instructions don't get the ordering guarantees
>> > from data dependences -- Paul, do you know of any such cases?
>>
>> A brief example wou
Re: Compiler support for erasure of sensitive data
On Mon, Feb 29, 2016 at 10:14 PM, Marcos Diaz wrote: > Hi, we are facing the same issue. This bugzilla was opened: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976 > > We were thinking on making a function attribute that ensures that non > necessary registers, or stack frames used by the function will be correctly > cleared before returning. > We think in implementing for x86_64 as a first work. > For this we are trying to modify the epilogue generation. Here we should have > the information of which registers this function used, and the size of the > stack frame to clean. The downside of this is that will be architecture > dependent. > Do you think this is a good idea? Do you suggest something else? I think you can't avoid doing architecture specific changes here. Note that on x86_64 you probably want to force -maccumulate-outgoing-args to avoid the use of push/pop and have the stack frame freeing fully in the epilogue. Richard. > Thanks.
