Re: GCC Bugzilla database dump
On Thu, Apr 11, 2013 at 6:40 PM, Shakthi Kannan wrote: > Hi, > > I would like to know if it is possible to get a database dump of the > GCC Bugzilla instance for analytics? > > http://gcc.gnu.org/bugzilla/ > > Please let me know. It's not possible. The database contains things such as usernames, passwords and e-mail addresses. Richard. > Thanks! > > SK > > -- > Shakthi Kannan > http://www.shakthimaan.com
RE: GCC Bugzilla database dump
My reply does not represent an official answer but I do know that this has come up before. The answer was that no, you cannot have a dump of the database for privacy reasons. You can however use web spider to get information directly from the webpages as long as you don't DoS the server. :) Cheers, Paulo Matos > -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of > Shakthi Kannan > Sent: 11 April 2013 17:41 > To: gcc@gcc.gnu.org > Subject: GCC Bugzilla database dump > > Hi, > > I would like to know if it is possible to get a database dump of the > GCC Bugzilla instance for analytics? > > http://gcc.gnu.org/bugzilla/ > > Please let me know. > > Thanks! > > SK > > -- > Shakthi Kannan > http://www.shakthimaan.com
Question on Gimple canonicalization
Hi, Consider the following sequence, which computes 2 addresses to access an array: _2 = (long unsigned int) i_1(D); _3 = _2 * 200; _4 = _3 + 1000; _6 = A2_5(D) + _4; *_6[0] = 1; _9 = _3 + 2000; _10 = A2_5(D) + _9; _11 = _2 * 4; _13 = A1_12(D) + _11; _14 = *_13; *_10[0] = _14; There is an opportunity for optimization here that the compiler misses, probably due to the order of Gimple statements. If we rewrite _3 = _2 * 200; _4 = _3 + 1000; _6 = A2_5(D) + _4; ... _9 = _3 + 2000; _10 = A2_5(D) + _9; as _3 = _2 * 200; _4 = _3 + A2_5(D); _6 = 1000 + _4; ... _9 = _3 + A2_5(D); _10 = 1000 + _9; We can clearly omit instruction _9. As the widening multiply pass has been improved to consider constant operands [1], this opportunity for optimization is lost as the widening multiply pass converts the sequence into: _3 = i_1(D) w* 200; _4 = WIDEN_MULT_PLUS_EXPR ; _6 = A2_5(D) + _4; ... _9 = WIDEN_MULT_PLUS_EXPR ; _10 = A2_5(D) + _9; With this particular example, this causes a Dhrystone regression at the AArch64 back end. Where in the front end could such an optimization take place? Bill, is this something that your Strength Reduction work [2] could be addressing? Thanks Sofiane - [1] http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01751.html [2] http://gcc.gnu.org/wiki/cauldron2012?action=AttachFile&do=get&target=wschmid t.pdf
Re: Question on Gimple canonicalization
On Fri, 2013-04-12 at 15:51 +0100, Sofiane Naci wrote: > Hi, > > Consider the following sequence, which computes 2 addresses to access an > array: > > _2 = (long unsigned int) i_1(D); > _3 = _2 * 200; > _4 = _3 + 1000; > _6 = A2_5(D) + _4; > *_6[0] = 1; > _9 = _3 + 2000; > _10 = A2_5(D) + _9; > _11 = _2 * 4; > _13 = A1_12(D) + _11; > _14 = *_13; > *_10[0] = _14; > > > There is an opportunity for optimization here that the compiler misses, > probably due to the order of Gimple statements. If we rewrite > > _3 = _2 * 200; > _4 = _3 + 1000; > _6 = A2_5(D) + _4; > ... > _9 = _3 + 2000; > _10 = A2_5(D) + _9; > > as > > _3 = _2 * 200; > _4 = _3 + A2_5(D); > _6 = 1000 + _4; > ... > _9 = _3 + A2_5(D); > _10 = 1000 + _9; > > We can clearly omit instruction _9. > > As the widening multiply pass has been improved to consider constant > operands [1], this opportunity for optimization is lost as the widening > multiply pass converts the sequence into: > > _3 = i_1(D) w* 200; > _4 = WIDEN_MULT_PLUS_EXPR ; > _6 = A2_5(D) + _4; > ... > _9 = WIDEN_MULT_PLUS_EXPR ; > _10 = A2_5(D) + _9; > > > With this particular example, this causes a Dhrystone regression at the > AArch64 back end. > > Where in the front end could such an optimization take place? > > Bill, is this something that your Strength Reduction work [2] could be > addressing? Hm, no, this isn't really a strength reduction issue. You're not wanting to remove an unwanted multiply. This is more of a reassociation/value numbering concern. Essentially you have: = A2 + ((i * 200) + 1000) = A2 + ((i * 200) + 2000) which you'd like to reassociate into = (A2 + (i * 200)) + 1000 = (A2 + (i * 200)) + 2000 so the parenthesized expression can be seen as available by value numbering: T = A2 + (i * 200) = T + 1000 = T + 2000 But reassociation just looks at a single expression tree and doesn't know about the potential optimization. I'm not sure this fits well into any of the existing passes, but others will have more authoritative answers than me... Bill > > Thanks > Sofiane > > - > > [1] http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01751.html > [2] > http://gcc.gnu.org/wiki/cauldron2012?action=AttachFile&do=get&target=wschmid > t.pdf > > > > >
GCC 4.6.4 Released
The GNU Compiler Collection version 4.6.4 has been released. GCC 4.6.4 is the last bug-fix release containing important fixes for regressions and serious bugs in GCC 4.6.3 with over 86 bugs fixed since the previous release. This release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank them individually!
GCC 4.6 branch is closed now
GCC 4.6.4 has been released. The 4.6 branch is now closed, please don't check anything there anymore. We have now two actively maintained releases as planned, 4.7.x and 4.8.x. Jakub
Re: Question on Gimple canonicalization
On Fri, 2013-04-12 at 11:18 -0500, Bill Schmidt wrote: > On Fri, 2013-04-12 at 15:51 +0100, Sofiane Naci wrote: > > Hi, > > > > Consider the following sequence, which computes 2 addresses to access an > > array: > > > > _2 = (long unsigned int) i_1(D); > > _3 = _2 * 200; > > _4 = _3 + 1000; > > _6 = A2_5(D) + _4; > > *_6[0] = 1; > > _9 = _3 + 2000; > > _10 = A2_5(D) + _9; > > _11 = _2 * 4; > > _13 = A1_12(D) + _11; > > _14 = *_13; > > *_10[0] = _14; > > > > > > There is an opportunity for optimization here that the compiler misses, > > probably due to the order of Gimple statements. If we rewrite > > > > _3 = _2 * 200; > > _4 = _3 + 1000; > > _6 = A2_5(D) + _4; > > ... > > _9 = _3 + 2000; > > _10 = A2_5(D) + _9; > > > > as > > > > _3 = _2 * 200; > > _4 = _3 + A2_5(D); > > _6 = 1000 + _4; > > ... > > _9 = _3 + A2_5(D); > > _10 = 1000 + _9; > > > > We can clearly omit instruction _9. > > > > As the widening multiply pass has been improved to consider constant > > operands [1], this opportunity for optimization is lost as the widening > > multiply pass converts the sequence into: > > > > _3 = i_1(D) w* 200; > > _4 = WIDEN_MULT_PLUS_EXPR ; > > _6 = A2_5(D) + _4; > > ... > > _9 = WIDEN_MULT_PLUS_EXPR ; > > _10 = A2_5(D) + _9; > > > > > > With this particular example, this causes a Dhrystone regression at the > > AArch64 back end. > > > > Where in the front end could such an optimization take place? > > > > Bill, is this something that your Strength Reduction work [2] could be > > addressing? > > Hm, no, this isn't really a strength reduction issue. You're not > wanting to remove an unwanted multiply. This is more of a > reassociation/value numbering concern. Essentially you have: > > = A2 + ((i * 200) + 1000) > = A2 + ((i * 200) + 2000) > > which you'd like to reassociate into > > = (A2 + (i * 200)) + 1000 > = (A2 + (i * 200)) + 2000 > > so the parenthesized expression can be seen as available by value > numbering: > > T = A2 + (i * 200) > = T + 1000 > = T + 2000 > > But reassociation just looks at a single expression tree and doesn't > know about the potential optimization. I'm not sure this fits well into > any of the existing passes, but others will have more authoritative > answers than me... All this said, it's not completely foreign to how the strength reduction pass is structured. The problem is that strength reduction looks for candidates of very restricted patterns, which keeps compile time down and avoids deep searching: (a * x) + b or a * (x + b). Your particular case adds only one more addend, but the number of ways that can be reassociated immediately adds a fair amount of complexity. If your example is extended to a two-dimensional array case, it becomes more complex still. So the methods used by strength reduction don't scale well to these more general problems. I imagine the existing canonical form for address calculations is good for some things, but not for others. Hopefully someone with more history in that area can suggest something. > > Bill > > > > > Thanks > > Sofiane > > > > - > > > > [1] http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01751.html > > [2] > > http://gcc.gnu.org/wiki/cauldron2012?action=AttachFile&do=get&target=wschmid > > t.pdf > > > > > > > > > >
AUTO: Sanjay Pamidiparti is out of the office (returning 04/15/2013)
I am out of the office until 04/15/2013. Please contact Nataraj Bhaskar (5-2644) for SURF/ACS/APMatrix, Eric Fuentes (5-5452) for Prodiance/Master Trust Vanchi (5-1633) for Lewtan/TRecs/UPCS/SNL/Prodiance & Kalle Kittelson (5-2480) for any other questions. Note: This is an automated response to your message "GCC 4.6.4 Released" sent on 04/12/2013 11:55:00. This is the only notification you will receive while this person is away. Please consider the environment before printing this email.
