Re: [PATCH] Fix a typo in two_value_replacement function
On Sun, May 05, 2019 at 01:31:12AM -0500, Li Jia He wrote:
> GCC revision 267634 implemented two_value_replacement function.
> However, a typo occurred during the parameter check, which caused
> us to miss some optimizations.
Thanks for catching this.
> The regression testing for the patch was done on GCC mainline on
>
> powerpc64le-unknown-linux-gnu (Power 9 LE)
>
> with no regressions. Is it OK for trunk and backport to gcc 9 ?
Ok for both, but see below.
> gcc/ChangeLog
>
> 2019-05-05 Li Jia He
>
> * tree-ssa-phiopt.c (two_value_replacement):
> Fix a typo in parameter detection.
Don't break a line after :, only when you reach 80 columns. So:
* tree-ssa-phiopt.c (two_value_replacement): Fix a typo in parameter
detection.
> * gcc.dg/pr88676.c: Modify the include header file.
> * gcc.dg/tree-ssa/pr37508.c: Add the no-ssa-phiopt option to
> skip phi optimization.
> * gcc.dg/tree-ssa/pr88676.c: Rename to ...
> * gcc.dg/tree-ssa/pr88676-1.c: ... this new file.
> * gcc.dg/tree-ssa/pr88676-2.c: New testcase.
Please don't rename tests unless really necessary. Just keep pr88676.c
and add pr88676-2.c next to it.
> --- a/gcc/testsuite/gcc.dg/pr88676.c
> +++ b/gcc/testsuite/gcc.dg/pr88676.c
> @@ -2,7 +2,7 @@
> /* { dg-do run } */
> /* { dg-options "-O2" } */
>
> -#include "tree-ssa/pr88676.c"
> +#include "tree-ssa/pr88676-1.c"
>
> __attribute__((noipa)) void
> bar (int x, int y, int z)
Thus remove this hunk.
> rename from gcc/testsuite/gcc.dg/tree-ssa/pr88676.c
> rename to gcc/testsuite/gcc.dg/tree-ssa/pr88676-1.c
And this one.
Jakub
[patch, committed] Fix gcc-7 regression in front-end optimization
Hello world,
I have just committed the attached patch as obvious after
regresson-testing - it fixed a rare beast, a gcc 7.4-only regression.
I have also committed the test case to trunk, to make sure that
this does not re-break. No real need to commit to the other
branches, I think.
Regards
Thomas
2019-05-05 Thomas Koenig
PR fortran/90344
* frontend-passes.c (create_var): Bring into sync with gcc 8.
2019-05-05 Thomas Koenig
PR fortran/90344
* gfortran.dg/pr90344.f90: New test.
Index: frontend-passes.c
===
--- frontend-passes.c (Revision 270881)
+++ frontend-passes.c (Arbeitskopie)
@@ -701,6 +701,11 @@ create_var (gfc_expr * e, const char *vname)
if (e->expr_type == EXPR_CONSTANT || is_fe_temp (e))
return gfc_copy_expr (e);
+ /* Creation of an array of unknown size requires realloc on assignment.
+ If that is not possible, just return NULL. */
+ if (flag_realloc_lhs == 0 && e->rank > 0 && e->shape == NULL)
+return NULL;
+
ns = insert_block ();
if (vname)
@@ -748,7 +753,7 @@ create_var (gfc_expr * e, const char *vname)
}
deferred = 0;
- if (e->ts.type == BT_CHARACTER && e->rank == 0)
+ if (e->ts.type == BT_CHARACTER)
{
gfc_expr *length;
@@ -759,6 +764,8 @@ create_var (gfc_expr * e, const char *vname)
else
{
symbol->attr.allocatable = 1;
+ symbol->ts.u.cl->length = NULL;
+ symbol->ts.deferred = 1;
deferred = 1;
}
}
@@ -771,7 +778,7 @@ create_var (gfc_expr * e, const char *vname)
result = gfc_get_expr ();
result->expr_type = EXPR_VARIABLE;
- result->ts = e->ts;
+ result->ts = symbol->ts;
result->ts.deferred = deferred;
result->rank = e->rank;
result->shape = gfc_copy_shape (e->shape, e->rank);
! { dg-do compile }
! { dg-additional-options "-ffrontend-optimize" }
! PR 90344 - this used to ICE.
! Test case by Urban Jost.
module M_xterm
contains
elemental function func1(ch) result(res)
character,intent(in) :: ch
logical :: res
res=.true.
end function func1
elemental function func2(ch) result(res)
character,intent(in) :: ch
logical :: res
res=.false.
end function func2
pure function s2a(string) RESULT (array)
character(len=*),intent(in) :: string
character(len=1):: array(len(string))
forall(i=1:len(string)) array(i) = string(i:i)
end function s2a
subroutine sub1()
write(*,*)all(func1(s2a('ABCDEFG')).or.func2(s2a('ABCDEFG')))
end subroutine sub1
end module M_xterm
Re: [PATCH, RFC, rs6000] PR80791 Consider doloop in ivopts
On Sun, May 05, 2019 at 12:04:00PM +0800, Bin.Cheng wrote: > On Sun, May 5, 2019 at 11:23 AM Kewen.Lin wrote: > > I can't really follow this. If it's predicted to be transformed to doloop, > > I think it should not be undoed any more, since it's useless to consider > > this cmp iv use. Whatever IVOPTS does, the comp at loop closing should not > > be changed (although possible to use other iv), right? Do I miss something? > As mentioned, the previous comment wasn't made on top of implementing > doloop in ivopts. That would be nice but a different story. > Before we can do that, it'd better be conservative and only makes > (doloop) decision in ivopts when you are sure. As you mentioned, it's > hard to do the same checks at gimple as RTL, right? In this case, > making it a (conservative) heuristic capturing certain beneficial > cases sounds better than capturing all cases but fail in later RTL > passes. But not *overly* conservative. If some situation almost never happens, it's better to have ivopts guess wrong some of the time than it is to just optimise less aggressively. If ivopts makes a non-optimal decision you still end up with valid code :-) Segher
New Swedish PO file for 'gcc' (version 9.1-b20190414)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: https://translationproject.org/latest/gcc/sv.po (This file, 'gcc-9.1-b20190414.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: A bug in vrp_meet?
> I have now applied this variant.
You backported it onto the 8 branch on Friday:
2019-05-03 Richard Biener
Backport from mainline
[...]
2019-03-07 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.
and this introduced a regression for the attached Ada testcase at -O:
Program received signal SIGSEGV, Segmentation fault.
0x0102173c in set_value_range (
vr=0x17747a0 , t=VR_RANGE, min=0x76c3df78, max=, equiv=0x0)
at /home/eric/svn/gcc-8-branch/gcc/tree-vrp.c:298
298 vr->type = t;
on x86-64 at least. Mainline and 9 branch are not affected.
--
Eric Botcazoupackage Opt78 is
subtype Reasonable is Integer range 1..10;
type UC (D: Reasonable := 2) is record
S: String (1 .. D) := "Hi";
end record;
type AUC is access all UC;
procedure Proc (P : UC; Msg : String);
end Opt78;
-- { dg-do compile }
-- { dg-options "-O" }
package body Opt78 is
procedure Proc (P : UC; Msg : String) is
Default : UC := (1, "!");
begin
if P = Default then
raise Program_Error;
else
raise Constraint_Error;
end if;
end;
end Opt78;
Re: [PATCH, RFC, rs6000] PR80791 Consider doloop in ivopts
On Sun, May 5, 2019 at 2:02 PM Kewen.Lin wrote:
>
> on 2019/5/5 下午12:04, Bin.Cheng wrote:
> > On Sun, May 5, 2019 at 11:23 AM Kewen.Lin wrote:
> + /* Some compare iv_use is probably useless once the doloop
> optimization
> + performs. */
> + if (tailor_cmp_p)
> +tailor_cmp_uses (data);
> >>> Function tailor_cmp_uses sets iv_use->zero_cost_p under some
> >>> conditions. Once the flag is set, though the iv_use participates cost
> >>> computation in determine_group_iv_cost_cond, the result cost is
> >>> hard-wired to ZERO (which means cost computation for such iv_use is
> >>> waste of time).
> >>
> >> Yes, it can be improved by some early check and return.
> >> But it's still helpful to make it call with may_eliminate_iv.
> >> gcc.dg/no-strict-overflow-6.c is one example, with may_eliminate_iv
> >> consideration it exposes more opportunities for downstream optimization.
> > Hmm, I wasn't suggesting early check and return, on the contrary, we
> > can better integrate doloop/cost stuff in the overall model. See more
> > in following comments.
>
> Sorry, I didn't claim it clearly, the previous comment is to claim the
> call with may_eliminate_iv is not completely "waste of time", and early
> return can make it save time. :)
>
> And yes, it's not an issue any more with your proposed idea.
>
> >>
> >>> Also iv_use rewriting process is skipped for related
> >>> ivs preserved explicitly by preserve_ivs_for_use.
> >>> Note IVOPTs already adds candidate for original ivs. So why not
> >>> detecting doloop iv_use, adjust its cost with the corresponding
> >>> original iv candidate, then let the general cost model make the
> >>> decision? I believe this better fits existing infrastructure and
> >>> requires less change, for example, preserve_ivs_for_use won't be
> >>> necessary.
> >> I agree adjusting the cost of original iv candidate of the iv_use
> >> requires less change, but on one hand, I thought to remove interest
> >> cmp iv use or make it zero cost is close to the fact. Since it's
> >> eliminated eventually in doloop optimization, it should not
> >> considered in cost modeling. This way looks more exact.
> > Whether doloop transformation should be considered or be bypassed in
> > cost model isn't a problem. Actually we can bind doloop iv_cand to
> > cmp iv_use in order to force the transformation. My concern is the
> > patch specially handles doloop by setting the special flag, then
> > checking it. We generally avoid such special-case handling since it
> > hurts long time maintenance. The pass was very unstable in the pass
> > because of such issues.
> >
>
> OK, I understand your concerns now. Thanks for explanation!
>
> >> One the other hand, I assumed your suggestion is to increase the
> >> cost for the pair (original iv cand, cmp iv use), the increase cost
> >> seems to be a heuristic value? It seems it's possible to sacrifice
> > Decrease the cost so that the iv_cand is preferred? The comment
> > wasn't made on top of implementing doloop in ivopts. Anyway, you can
> > still bypass cost model by binding the "correct" iv_cand to cmp
> > iv_use.
> >
>
> To decrease the cost isn't workable for this case, it make the original
> iv cand is preferred more and over the other iv cand for memory iv use,
> then the desirable memory based iv cand won't be chosen.
> If increase the cost, one basic iv cand is chosen for cmp use, memory
> based iv cand is chosen for memory use, instead of original iv for both.
Sorry for the mistake, I meant to decrease use cost of whatever "correct"
iv_cand for cmp iv_use that could enable doloop optimization, it doesn't
has to the original iv_cand.
>
> Could you help to explain the "binding" more? Does it mean cost modeling
> decision making can simply bypass the cmp iv_use (we have artificially
> assigned one "correct" cand iv to it) and also doesn't count the "correct"
> iv cand cost into total iv cost? Is my understanding correct?
For example, if the heuristic finds out the "correct" doloop iv_cand, we can
force choosing that iv_cand for cmp iv_use and bypass the candidate choosing
algorithm:
struct iv_group {
//...
struct iv_cand *bind_cand;
};
then set this bind_cand directly in struct iv_ca::cand_for_group. As a result,
iv_use rewriting code takes care of everything, no special handling (such as
preserve_ivs_for_use) is needed.
Whether letting cost model decide the "correct" iv_cand or bind it by yourself
depends on how good your heuristic check is. It's your call. :)
>
> >>> tuning; 2) the doloop decision can still be canceled by cost model if
> >>> it's really not beneficial. With current patch, it can't be undo once
> >>> the decision is made (at very early stage in IVOPTs.).
> >>
> >> I can't really follow this. If it's predicted to be transformed to doloop,
> >> I think it should not be undoed any more, since it's useless to consider
> >> this cmp iv use. Whatever IVOPTS does, the comp at loop closing should not
>
Re: [PATCH] Loop split upon semi-invariant condition (PR tree-optimization/89134)
Hi Richard,
Since gcc 9 has been released, will you get some time to take a look at this
patch? Thanks.
Feng
From: Richard Biener
Sent: Tuesday, March 12, 2019 4:31:49 PM
To: Feng Xue OS
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Loop split upon semi-invariant condition (PR
tree-optimization/89134)
On Tue, Mar 12, 2019 at 7:20 AM Feng Xue OS wrote:
>
> This patch is composed to implement a loop transformation on one of its
> conditional statements, which we call it semi-invariant, in that its
> computation is impacted in only one of its branches.
>
> Suppose a loop as:
>
> void f (std::map m)
> {
> for (auto it = m.begin (); it != m.end (); ++it) {
> /* if (b) is semi-invariant. */
> if (b) {
> b = do_something();/* Has effect on b */
> } else {
> /* No effect on b */
> }
> statements; /* Also no effect on b */
> }
> }
>
> A transformation, kind of loop split, could be:
>
> void f (std::map m)
> {
> for (auto it = m.begin (); it != m.end (); ++it) {
> if (b) {
> b = do_something();
> } else {
> ++it;
> statements;
> break;
> }
> statements;
> }
>
> for (; it != m.end (); ++it) {
> statements;
> }
> }
>
> If "statements" contains nothing, the second loop becomes an empty one, which
> can be removed. (This part will be given in another patch). And if
> "statements" are straight line instructions, we get an opportunity to
> vectorize the second loop. In practice, this optimization is found to improve
> some real application by %7.
>
> Since it is just a kind of loop split, the codes are mainly placed in
> existing tree-ssa-loop-split module, and is controlled by -fsplit-loop, and
> is enabled with -O3.
Note the transform itself is jump-threading with the threading
duplicating a whole CFG cycle.
I didn't look at the patch details yet since this is suitable for GCC 10 only.
Thanks for implementing this.
Richard.
> Feng
>
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 64bf6017d16..a6c2878d652 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,23 @@
> +2019-03-12 Feng Xue
> +
> + PR tree-optimization/89134
> +* doc/invoke.texi (max-cond-loop-split-insns): Document new --params.
> + (min-cond-loop-split-prob): Likewise.
> + * params.def: Add max-cond-loop-split-insns, min-cond-loop-split-prob.
> + * passes.def (pass_cond_loop_split) : New pass.
> + * timevar.def (TV_COND_LOOP_SPLIT): New time variable.
> + * tree-pass.h (make_pass_cond_loop_split): New declaration.
> + * tree-ssa-loop-split.c (split_info): New class.
> + (find_vdef_in_loop, vuse_semi_invariant_p): New functions.
> + (ssa_semi_invariant_p, stmt_semi_invariant_p): Likewise.
> + (can_branch_be_excluded, get_cond_invariant_branch): Likewise.
> + (is_cond_in_hidden_loop, compute_added_num_insns): Likewise.
> + (can_split_loop_on_cond, mark_cond_to_split_loop): Likewise.
> + (split_loop_for_cond, tree_ssa_split_loops_for_cond): Likewise.
> + (pass_data_cond_loop_split): New variable.
> + (pass_cond_loop_split): New class.
> + (make_pass_cond_loop_split): New function.
> +
> 2019-03-11 Jakub Jelinek
>
> PR middle-end/89655
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index df0883f2fc9..f5e09bd71fd 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -11316,6 +11316,14 @@ The maximum number of branches unswitched in a
> single loop.
> @item lim-expensive
> The minimum cost of an expensive expression in the loop invariant motion.
>
> +@item max-cond-loop-split-insns
> +The maximum number of insns to be increased due to loop split on
> +semi-invariant condition statement.
> +
> +@item min-cond-loop-split-prob
> +The minimum threshold for probability of semi-invaraint condition
> +statement to trigger loop split.
> +
> @item iv-consider-all-candidates-bound
> Bound on number of candidates for induction variables, below which
> all candidates are considered for each use in induction variable
> diff --git a/gcc/params.def b/gcc/params.def
> index 3f1576448be..2e067526958 100644
> --- a/gcc/params.def
> +++ b/gcc/params.def
> @@ -386,6 +386,18 @@ DEFPARAM(PARAM_MAX_UNSWITCH_LEVEL,
> "The maximum number of unswitchings in a single loop.",
> 3, 0, 0)
>
> +/* The maximum number of increased insns due to loop split on semi-invariant
> + condition statement. */
> +DEFPARAM(PARAM_MAX_COND_LOOP_SPLIT_INSNS,
> + "max-cond-loop-split-insns",
> + "The maximum number of insns to be increased due to loop split on
> semi-invariant condition statement.",
> +
Re: [PATCH] Error only when -mabi=ms is used on a non-MS_ABI system (PR sanitizer/90312).
On Fri, May 03, 2019 at 12:51:09PM +0200, Martin Liška wrote: > 2019-05-02 Martin Liska > > PR sanitizer/90312 > * config/i386/i386.c (ix86_option_override_internal): Error only > when -mabi is selected to a non-default version. > > gcc/testsuite/ChangeLog: > > 2019-05-02 Martin Liska > > PR sanitizer/90312 > * gcc.dg/asan/pr87930.c: Run the test only on *linux or *gnu > systems. > * gcc.dg/tsan/pr88017.c: Likewise. Ok, thanks. Jakub
