Request for update of documentation about `-mtune`
Hello, Today I have noticed that latest GCC documentation still has (https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-mtune-17) -mtune=cpu-type ... ... ‘intel’ Produce code optimized for the most current Intel processors, which are Haswell and Silvermont for this version of GCC. ... Is this choice still the case, or is it just that the documentation hasn't been updated? Haswell and Silvermont were released about a decade ago and shouldn't be considered 'the most current Intel processors'. `-march=haswell` actually generates code that runs ~15% slower on my TigerLake CPU. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature
Need some analyzer testcase help
Hi David and others,
I am in the process of improving phi-opt and moving what was handled
in value_replacement to match-and-simplify and ran into a few failures
in the analyzer testsuite.
For an example c-c++-common/analyzer/inlining-3-multiline.c (and
c-c++-common/analyzer/inlining-3.c) now fails due to optimizing away
the if statement in get_input_file_name so it just returns its
argument and we don't get a comparison against NULL any more.
Should we change the testcase to avoid this transformation or should
we avoid this transformation early on during optimization phases? Or
something else like move analyzer earlier before phiopt?
Attached is the patch which shows the 2 testsuite failures. I have not
done a full bootstrap with it; just a build and run the testsuite.
Thanks,
Andrew
From 02324ac702fb5e39ccfdbd4910b5240762679593 Mon Sep 17 00:00:00 2001
From: Andrew Pinski
Date: Thu, 26 Oct 2023 16:06:33 -0700
Subject: [PATCH] MATCH: Move jump_function_from_stmt support to match.pd
This moves the value_replacement support for jump_function_from_stmt
to match pattern.
This allows us to optimize things earlier in phiopt1 rather than waiting
to phiopt2. Which means phiopt1 needs to be disable for vrp03.c testcase.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* match.pd (PTR == 0 ? 0 : &PTR->field): New pattern.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/vrp03.c: Disable phiopt1.
---
gcc/match.pd | 21 +
gcc/testsuite/gcc.dg/tree-ssa/vrp03.c | 2 +-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/gcc/match.pd b/gcc/match.pd
index eed3083a827..eebd64b24ad 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -4135,6 +4135,27 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(cond (eq @0 integer_zerop) @1 (op@2 @1 @0))
@2))
+/* PTR == 0 ? 0 : &PTR->field -> PTR if field offset was 0. */
+(simplify
+ (cond (eq @0 integer_zerop) integer_zerop ADDR_EXPR@1)
+ (with {
+ poly_int64 offset;
+ tree res = NULL_TREE;
+ tree tem = @1;
+ if (TREE_CODE (tem) == SSA_NAME)
+ if (gassign *def = dyn_cast (SSA_NAME_DEF_STMT (tem)))
+ if (gimple_assign_rhs_code (def) == ADDR_EXPR)
+ tem = gimple_assign_rhs1 (def);
+
+ if (TREE_CODE (tem) == ADDR_EXPR)
+ res = get_addr_base_and_unit_offset (TREE_OPERAND (tem, 0), &offset);
+ }
+ (if (res
+ && TREE_CODE (res) == MEM_REF
+ && known_eq (mem_ref_offset (res) + offset, 0)
+ && operand_equal_p (TREE_OPERAND (res, 0), @0))
+ (convert @0
+
/* Simplifications of shift and rotates. */
(for rotate (lrotate rrotate)
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp03.c
b/gcc/testsuite/gcc.dg/tree-ssa/vrp03.c
index 4cbaca41332..1adbf33cad3 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/vrp03.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp03.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O2 -fdisable-tree-evrp -fdump-tree-vrp1 -fno-thread-jumps" }
*/
+/* { dg-options "-O2 -fdisable-tree-evrp -fdump-tree-vrp1 -fno-thread-jumps
-fdisable-tree-phiopt1" } */
struct A
{
--
2.39.3
Please link to my website https://ecards.hopespring.org.uk/
Hey, I trust this message finds you well. I'm writing to propose a mutually beneficial collaboration. I've been impressed by the quality and relevance of your content, and I believe our websites share a common interest. I'd like to kindly request that you consider placing a link to my website, https://ecards.hopespring.org.uk/, within your content. This collaboration could enhance the value you offer to your audience while providing exposure to my site. I'm open to discussing any terms or conditions that work best for you. Please feel free to reach out with any questions or concerns. Thank you for considering this partnership opportunity. Warm regards, Oladosu
Re: Need some analyzer testcase help
On Fri, 2023-10-27 at 12:48 -0700, Andrew Pinski wrote: > Hi David and others, > I am in the process of improving phi-opt and moving what was > handled > in value_replacement to match-and-simplify and ran into a few > failures > in the analyzer testsuite. > For an example c-c++-common/analyzer/inlining-3-multiline.c (and > c-c++-common/analyzer/inlining-3.c) now fails due to optimizing away > the if statement in get_input_file_name so it just returns its > argument and we don't get a comparison against NULL any more. > > Should we change the testcase to avoid this transformation or should > we avoid this transformation early on during optimization phases? Or > something else like move analyzer earlier before phiopt? The analyzer runs relatively late, and moving it would be a major task. The intent of those testcases is to verify that the analyzer can provide the user with a sufficiently readable execution path (the path of execution events that triggers a problem) i.e. that we can reconstruct things in the face of inlining. Those conditionals are intended as examples of control-flow logic that we'd want to display to the user. Hence it's probably best to disable your new optimization on these testcases (presumably by adding "-fdisable-tree-phiopt1"), so that we keep that control flow logic. Does that make sense? Dave
Re: Need some analyzer testcase help
On Fri, Oct 27, 2023 at 2:12 PM David Malcolm wrote: > > On Fri, 2023-10-27 at 12:48 -0700, Andrew Pinski wrote: > > Hi David and others, > > I am in the process of improving phi-opt and moving what was > > handled > > in value_replacement to match-and-simplify and ran into a few > > failures > > in the analyzer testsuite. > > For an example c-c++-common/analyzer/inlining-3-multiline.c (and > > c-c++-common/analyzer/inlining-3.c) now fails due to optimizing away > > the if statement in get_input_file_name so it just returns its > > argument and we don't get a comparison against NULL any more. > > > > > Should we change the testcase to avoid this transformation or should > > we avoid this transformation early on during optimization phases? Or > > something else like move analyzer earlier before phiopt? > > The analyzer runs relatively late, and moving it would be a major task. > > The intent of those testcases is to verify that the analyzer can > provide the user with a sufficiently readable execution path (the path > of execution events that triggers a problem) i.e. that we can > reconstruct things in the face of inlining. > > Those conditionals are intended as examples of control-flow logic that > we'd want to display to the user. > > Hence it's probably best to disable your new optimization on these > testcases (presumably by adding "-fdisable-tree-phiopt1"), so that we > keep that control flow logic. > > Does that make sense? Yes this makes perfect sense; I was just double checking to make sure we were not losing some diagnostic that would be useful to the user with respect to this change. Thanks, Andrew > > Dave >
gcc-12-20231027 is now available
Snapshot gcc-12-20231027 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20231027/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-12 revision 7caab3cbcf86dc90d0a43a4447e70794bad1363e You'll find: gcc-12-20231027.tar.xz Complete GCC SHA256=6b76dcf632429d78987119874734189828e263092cbc628e083739574cc25caf SHA1=06d1db338004704694ab734847f9e195a6cb52d3 Diffs from 12-20231020 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 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.
