https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #21 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:dddb6ffdc5c25264dd75ad82dad8e48a0718d2d9
commit r12-2270-gdddb6ffdc5c25264dd75ad82dad8e48a0718d2d9
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #20 from Jakub Jelinek ---
Created attachment 51144
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51144&action=edit
gcc12-pr101419.patch
Updated patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #19 from rguenther at suse dot de ---
On Mon, 12 Jul 2021, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
>
> --- Comment #18 from Jakub Jelinek ---
> (In reply to rguent...@suse.de from comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #18 from Jakub Jelinek ---
(In reply to rguent...@suse.de from comment #16)
> Well, my point was to avoid pessimizing the VN done from cunrolli ;)
> Of course any duplication / threading can improve __bos precision,
> but then any tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #17 from rguenther at suse dot de ---
On Mon, 12 Jul 2021, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
>
> --- Comment #15 from Jakub Jelinek ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #16 from rguenther at suse dot de ---
On Mon, 12 Jul 2021, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
>
> --- Comment #14 from Jakub Jelinek ---
> I agree about most of the passes you are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #15 from Jakub Jelinek ---
(In reply to Richard Biener from comment #13)
> Note usually we still run all property providers but the way you set
> the property outside of pass->properties_provided breaks this. Thus
> maybe split objs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #14 from Jakub Jelinek ---
I agree about most of the passes you are moving, but I have an (albeit
artificial) testcase that proves that cunrolli does affect objsz:
__SIZE_TYPE__ a[10];
void
foo (void)
{
char *p = __builtin_malloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #13 from Richard Biener ---
(In reply to Richard Biener from comment #12)
> (In reply to Jakub Jelinek from comment #10)
> > Created attachment 51139 [details]
> > gcc12-pr101419.patch
> >
> > Full untested patch.
>
> I guess that'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #12 from Richard Biener ---
(In reply to Jakub Jelinek from comment #10)
> Created attachment 51139 [details]
> gcc12-pr101419.patch
>
> Full untested patch.
I guess that's certainly what was intended (and after the patch more expl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #11 from Richard Biener ---
I think none of
NEXT_PASS (pass_complete_unrolli);
NEXT_PASS (pass_backprop);
NEXT_PASS (pass_phiprop);
NEXT_PASS (pass_forwprop);
are useful for objsize so IMHO we should move pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #9 from Jakub Jelinek ---
The above patch will slightly pessimize optimizations during the
NEXT_PASS (pass_remove_cgraph_callee_edges);
/* Initial scalar cleanups before alias computation.
They ensure memory acce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #8 from Jakub Jelinek ---
--- gcc/tree-pass.h.jj 2021-01-27 10:10:00.525903635 +0100
+++ gcc/tree-pass.h 2021-07-12 13:10:59.621933276 +0200
@@ -208,6 +208,7 @@ protected:
#define PROP_gimple_lcf(1 << 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #7 from Jakub Jelinek ---
It is the cunrolli pass where things go wrong (it VNs the &u->c for both
__builtin_object_size calls while previously only the first one was &u->c and
the second was &u->i).
Now, objsz2 obviously needs to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #6 from Richard Biener ---
Nothing can "fix" __builtin_object_size here (on sub-objects) without changing
how we represent and CSE addresses, esp. if you consider inlining where we
want to interpret __builtin_object_size (p, ..) as h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
Jakub Jelinek changed:
What|Removed |Added
CC||siddhesh at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #4 from Jakub Jelinek ---
--- gcc/tree-object-size.c.jj 2021-01-04 10:25:39.911221618 +0100
+++ gcc/tree-object-size.c 2021-07-12 11:28:51.328120222 +0200
@@ -1393,6 +1393,11 @@ pass_object_sizes::execute (function *fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #3 from Richard Biener ---
(In reply to Jakub Jelinek from comment #2)
> Started with r9-2635-g78ea9abc2018243af7f7ada6135144ac90c6ad27
> I wonder if objsz pass when insert_min_max_p shouldn't in addition to adding
> MIN_EXPR or MAX_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |9.5
Summary|collapsing memse
20 matches
Mail list logo
