Ryzen PPA znver1 optimizations
I have been working on some PPA's that will provide standard Ubuntu and Linux Mint packages that are compiled with the znver1 cpu optimisations (Ryzen CPU). It has been quite tedious (though not particularly hard) to modify existing packages to be compiled with "-march=znver1" cflags and cxxflags, and since I started creating a toolchain to make the builds in the PPAs compile more reliably while producing broken less packages, I decided to modify GCC to always spit out ryzen optimised code automatically regardless of what code is thrown at it. I changed each instance of =generic in gcc/config.gcc to =znver1, and each instance of cpu= to cpu=znver1, and each instance of arch= that wasn't i386, i486, i586, i686, i786, x86-64, or x86_64 to arch=znver1. So what I think will happen is that I will set a PPA with a dependency on the PPA with the modified GCC, and any package I upload/copy to the aforementioned PPA that is compiling to x86 code will compile as though I set the "-march=znver1" option. Does anyone know whether or not this is going to work the way I think it will, or know how I can test to see if such is the case with the resulting binary packages? Also, is there a better way to do what I am trying to do?
Re: Signed-unsigned comparison question
Correction: The construct gcc complains about is not if ( a < b ) ... but if ( a < b - ( b >> 2 ) ) ... but still the same applies. The RHS of the > operator can never be negative or have an overflow on 32 bits. On Fri, 8 Mar 2019 10:40:06 +1100 Zoltan Kocsi wrote: > Gcc 8.2.0 (arm-none-eabi) throws a warning on the following construct: > > uint32_t a; > uint16_t b; > > if ( a > b ) ... > > compaining that a signed integer is compared against an unsigned. > Of course, it is correct, as 'b' was promoted to int. > > But shouldn't it be smart enough to know that (int) b is restricted to > the range of [0,65535] which it can safely compare against the range > of [0,0xu]? > > Thanks, > > Zoltan
Signed-unsigned comparison question
Gcc 8.2.0 (arm-none-eabi) throws a warning on the following construct: uint32_t a; uint16_t b; if ( a > b ) ... compaining that a signed integer is compared against an unsigned. Of course, it is correct, as 'b' was promoted to int. But shouldn't it be smart enough to know that (int) b is restricted to the range of [0,65535] which it can safely compare against the range of [0,0xu]? Thanks, Zoltan
gcc-7-20190307 is now available
Snapshot gcc-7-20190307 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190307/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 269471 You'll find: gcc-7-20190307.tar.xzComplete GCC SHA256=3b16968750a86c81e882917c4808a1df73df2f62a911e33fa542537a7c36d1a2 SHA1=77020aef92c14db02aa332431041e05ae43bc648 Diffs from 7-20190228 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 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: GSoC Project Ideas
On 3/4/19 6:17 AM, Richard Biener wrote:
On Mon, Mar 4, 2019 at 1:23 PM Jakub Jelinek wrote:
On Mon, Mar 04, 2019 at 01:13:29PM +0100, Richard Biener wrote:
* Make TREE_NO_WARNING more fine-grained
(inspired by comment #7 of PR74762 [3])
TREE_NO_WARNING is currently used as a catch-all marker that inhibits all
warnings related to the marked expression. The problem with this is that
if some warning routine sets the flag for its own purpose,
then that later may inhibit another unrelated warning from firing, see
for
example PR74762. Implementing a more fine-grained mechanism for
inhibiting particular warnings would eliminate such issues.
Might be interesting. You'd probably need to discuss the details further.
I guess an implementation could use TREE_NO_WARNING (or gimple_no_warning_p)
as indicator that there's out-of-bad detail information which could be stored as
a map keyed off either a location or a tree or gimple *.
I guess on tree or gimple * is better, there would need to be some hook for
copy_node/gimple_copy that would add the info for the new copy as well if
the TREE_NO_WARNING or gimple_no_warning_p bit was set. Plus there could be
some purging of this on the side information, e.g. once code is handed over
from the FE to the middle-end (maybe do that only at free_lang_data time),
for any warnings that are FE only there is no need to keep records in the on
the side mapping that have info about those FE warnings only, as later on
the FE warnings will not be reported anymore.
The implementation could be e.g. a hash map from tree/gimple * (pointers) to
bitmaps of warning numbers, with some hash table to ensure that the same
bitmap is used for all the spots that need to have the same set of warnings
disabled.
A possibly related project is to "defer" output of diagnostics until we know
the stmt/expression we emit it for survived dead code elimination. Here there's
the question what to key the diagnostic off and how to move it (that is, detect
if the code causing it really fully went dead).
Another (maybe only remotely related) aspect of this project might
be getting #pragma GCC diagnostic to work reliably with middle-end
warnings emitted for inlined code. That it doesn't work is one of
the frustrations for users who run into false positives with "late"
warnings like -Wstringop-overflow or -Wformat-overflow.
I'm sure there are bugs that track this but here's a test case
involving -Warray-bounds:
int a[3];
int f (int i)
{
return a[i];
}
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Warray-bounds"
int g (void)
{
return f (7); // expect no -Warray-bounds
}
#pragma GCC diagnostic pop
int h (void)
{
return f (7); // expect -Warray-bounds
}
Martin
Re: A bug in vrp_meet?
On Wed, Mar 6, 2019 at 11:05 AM Richard Biener wrote: > > On Tue, Mar 5, 2019 at 10:36 PM Jeff Law wrote: > > > > On 3/5/19 7:44 AM, Richard Biener wrote: > > > > > So fixing it properly with also re-optimize_stmt those stmts so we'd CSE > > > the MAX_EXPR introduced by folding makes it somewhat ugly. > > > > > > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. > > > > > > Any ideas how to make it less so? I can split out making optimize_stmt > > > take a gsi * btw, in case that's a more obvious change and it makes the > > > patch a little smaller. > > > > > > Richard. > > > > > > 2019-03-05 Richard Biener > > > > > > PR tree-optimization/89595 > > > * tree-ssa-dom.c (dom_opt_dom_walker::optimize_stmt): Take > > > stmt iterator as reference, take boolean output parameter to > > > indicate whether the stmt was removed and thus the iterator > > > already advanced. > > > (dom_opt_dom_walker::before_dom_children): Re-iterate over > > > stmts created by folding. > > > > > > * gcc.dg/torture/pr89595.c: New testcase. > > > > > > > Well, all the real logic changs are in the before_dom_children method. > > The bits in optimize_stmt are trivial enough to effectively ignore. > > > > I don't see a better way to discover and process statements that are > > created in the bowels of fold_stmt. > > I'm not entirely happy so I created the following alternative which > is a bit larger and slower due to the pre-pass clearing the visited flag > but is IMHO easier to follow. I guess there's plenty of TLC opportunity > here but then I also hope to retire the VN parts of DOM in favor > of the non-iterating RPO-VN code... > > So - I'd lean to this variant even though it has the extra loop over stmts, > would you agree? I have now applied this variant. Richard. > Bootstrap / regtest running on x86_64-unknown-linux-gnu. > > Richard. > > 2019-03-06 Richard Biener > > PR tree-optimization/89595 > * tree-ssa-dom.c (dom_opt_dom_walker::optimize_stmt): Take > stmt iterator as reference, take boolean output parameter to > indicate whether the stmt was removed and thus the iterator > already advanced. > (dom_opt_dom_walker::before_dom_children): Re-iterate over > stmts created by folding. > > * gcc.dg/torture/pr89595.c: New testcase.
