https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #58 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:4ba4165d66b18d7c5b8af02ecdf38bfa0690c106
commit r15-4017-g4ba4165d66b18d7c5b8af02ecdf38bfa0690c106
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #57 from Andrew Macleod ---
FWIW, on my last run, enabling early VRP sped up my -O1 compilation by a fair
amount. total compilation dropped from 480 seconds to 380 seconds...
It took 2.5 seconds to run, and im going to guess might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #56 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:942bbb2357656019caa3f8ebd2d23b09222f039a
commit r15-3896-g942bbb2357656019caa3f8ebd2d23b09222f039a
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #55 from Andrew Macleod ---
(In reply to Richard Biener from comment #50)
> (In reply to Richard Biener from comment #4)
> > Trunk at -O1:
> >
> > dominator optimization : 495.14 ( 82%) 0.20 ( 5%) 495.44 (
> > 81%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #54 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:9b7626383822799d60ea3c62e62e700f16337cd6
commit r15-3860-g9b7626383822799d60ea3c62e62e700f16337cd6
Author: Aldy Hernandez
Date:
rguenther at suse dot de via Gcc-bugs writes:
>> Have you tried the patch in comment 22? That should reduce the time in
>> DOM by 23%.
>
> I thought that was already applied ...?
No. I wanted to investigate the 3 missing threads, but I think the
patch can go in as is. I'll be away for a few
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #53 from aldy at quesejoda dot com ---
rguenther at suse dot de via Gcc-bugs writes:
>> Have you tried the patch in comment 22? That should reduce the time in
>> DOM by 23%.
>
> I thought that was already applied ...?
No. I want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #52 from rguenther at suse dot de ---
On Wed, 25 Sep 2024, aldy at quesejoda dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
>
> --- Comment #51 from aldy at quesejoda dot com ---
> "rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #51 from aldy at quesejoda dot com ---
"rguenth at gcc dot gnu.org via Gcc-bugs" writes:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
>
> --- Comment #50 from Richard Biener ---
> (In reply to Richard Biener from comment #
"rguenth at gcc dot gnu.org via Gcc-bugs" writes:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
>
> --- Comment #50 from Richard Biener ---
> (In reply to Richard Biener from comment #4)
>> Trunk at -O1:
>>
>> dominator optimization : 495.14 ( 82%) 0.20 ( 5%) 495.44 (
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #50 from Richard Biener ---
(In reply to Richard Biener from comment #4)
> Trunk at -O1:
>
> dominator optimization : 495.14 ( 82%) 0.20 ( 5%) 495.44 (
> 81%) 113M ( 5%)
Compared to that we're now at the following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #49 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:cc141b56b367b3d81c1b590e22ae174f1e013009
commit r15-3854-gcc141b56b367b3d81c1b590e22ae174f1e013009
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #48 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:caf3fe7880e62692da45489dc5bcae069c1555c8
commit r15-3852-gcaf3fe7880e62692da45489dc5bcae069c1555c8
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #47 from Sam James ---
> gcc.exe (x86_64-win32-sjlj-rev0, Built by MinGW-W64 project) 5.1.0
GCC 5 is long EOL, unfortunately.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #46 from jeremy rutman ---
I don't know if this is relevant but a certain gcc I was using lately seems to
do fine compiling one of the autogenerated files in question (an AES128 encrypt
file) , but quits unexpectedly when I try compi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #45 from Richard Biener ---
I noticed that
get_bitmask_from_range(tree_node*, generic_wide_int const&,
generic_wide_int const&)
is quite high on the profile accumulating profile hits on
wide_int_storage::operator=(wide_int_storage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #44 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:9a795b3a5b6a0d8b4b4f38a66ab9782aabead92e
commit r15-3824-g9a795b3a5b6a0d8b4b4f38a66ab9782aabead92e
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #43 from Richard Biener ---
Thanks for the work sofar. It seems the back_jt_path_registry::update_cfg
has a "dead" guard against un-adjust_paths_after_duplication paths with
its tracking visited_starting_edges, so for the purpose of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #42 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:f9dfe8dea31bf5c56aa7798a0905707faf9e7ec4
commit r15-3818-gf9dfe8dea31bf5c56aa7798a0905707faf9e7ec4
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #41 from Aldy Hernandez ---
Created attachment 59181
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59181&action=edit
unrtested patch sorting threadable paths
The performance improvement with this patch is:
** mainline
Time v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #40 from Aldy Hernandez ---
For the record, I still think adjust_paths_after_duplication() isn't giving us
much for all the hassle it's causing.
I compared the number of threaded paths with and without it and the difference
is:
* m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #39 from Aldy Hernandez ---
I'm going to step away from this PR for a few weeks so I'll do a brain dump on
where I am, just in case someone wants to poke at it some more.
This problem in adjust_paths_after_duplication() boils down t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #38 from aldy at quesejoda dot com ---
On Tue, Sep 17, 2024 at 1:19 PM rguenther at suse dot de <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
>
> --- Comment #37 from rguenther at suse dot d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #37 from rguenther at suse dot de ---
On Tue, 17 Sep 2024, aldyh at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
>
> --- Comment #36 from Aldy Hernandez ---
> (In reply to Richard Biener from commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #36 from Aldy Hernandez ---
(In reply to Richard Biener from comment #33)
> Can we just sort m_paths after the path entry BB and fix the lookup that way?
This seemed promising, especially because the adjust_paths_after_duplication()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #35 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #34)
> Btw, if we simply remove the call to that function, with -O1
> -fenable-tree-thread1 I see:
>
> backwards jump threading : 14.36 ( 3%) 0.39 (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #34 from Andrew Macleod ---
Btw, if we simply remove the call to that function, with -O1
-fenable-tree-thread1 I see:
backwards jump threading : 14.36 ( 3%) 0.39 ( 5%) 14.68 ( 3%)
238M ( 9%)
which is a notable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #33 from Richard Biener ---
Can we just sort m_paths after the path entry BB and fix the lookup that way?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #32 from Richard Biener ---
(In reply to Aldy Hernandez from comment #31)
> (In reply to rguent...@suse.de from comment #30)
> > On Wed, 4 Sep 2024, amacleod at redhat dot com wrote:
>
> > > I tried running valgrind, which died, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
Aldy Hernandez changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #30 from rguenther at suse dot de ---
On Wed, 4 Sep 2024, amacleod at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
>
> --- Comment #29 from Andrew Macleod ---
> Huh. Do we calculate *all* paths ahead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #29 from Andrew Macleod ---
Huh. Do we calculate *all* paths ahead of time?
I tried running valgrind, which died, but up to that point it showed 77% of the
time spend in the body of
back_jt_path_registry::adjust_paths_after_duplica
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #28 from Richard Biener ---
Just to clarify what the "handcuffs" in the backwards threader do and what
they don't. There is no limit on the number of cond/switch stmts (thus
basic-blocks) we consider as the exit of paths, but for ea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #27 from Andrew Macleod ---
(In reply to Aldy Hernandez from comment #26)
>
> With -O1 -fenable-tree-thread1 (no threadfull):
> dominator optimization : 127.76 ( 7%) 0.57 ( 7%) 128.58 (
> 7%) 236M ( 9%)
> back
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #26 from Aldy Hernandez ---
I think there's something fundamentally wrong in the *backwards* threader that
causes us to blow up, even without fully resolving conditions with a global
ranger.
I tried running at -O1 and -fenable-tree-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #25 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #22)
> Created attachment 59001 [details]
> reduce recursion in forward threader (patch in testing)
Avoiding unnecessary recursion in simplify_control_stmt_conditi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #24 from Aldy Hernandez ---
(In reply to Richard Biener from comment #13)
> Most of the -O1 dom time is spent in threading using path ranger to simplify
> the JT conditions. That in turn does (for each threading from scratch?)
> GOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #23 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #22)
> Created attachment 59001 [details]
> reduce recursion in forward threader (patch in testing)
>
> As suggested by Richard in PR116166.
Should've been more v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #22 from Aldy Hernandez ---
Created attachment 59001
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59001&action=edit
reduce recursion in forward threader (patch in testing)
As suggested by Richard in PR116166.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #21 from Richard Biener ---
(In reply to Andrew Macleod from comment #20)
> I did an -O2 run after those patches.
>
> Highlights:
>
> tree SSA incremental : 117.74 ( 1%) 0.63 ( 3%) 120.37 (
> 1%) 1049M ( 24%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #20 from Andrew Macleod ---
I did an -O2 run after those patches.
Highlights:
tree SSA incremental : 117.74 ( 1%) 0.63 ( 3%) 120.37 ( 1%)
1049M ( 24%)
dominator optimization : 680.49 ( 5%) 0.65
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #19 from Andrew Macleod ---
(In reply to GCC Commits from comment #17)
> The master branch has been updated by Andrew Macleod :
>
> https://gcc.gnu.org/g:9e4da946c4263a4c89d5fc365b3c97ae244c5018
>
> commit r15-2858-g9e4da946c4263a4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
Sam James changed:
What|Removed |Added
See Also||https://github.com/GaloisIn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #17 from GCC Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:9e4da946c4263a4c89d5fc365b3c97ae244c5018
commit r15-2858-g9e4da946c4263a4c89d5fc365b3c97ae244c5018
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #16 from GCC Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:5ce3874b3c2fdd76f506005cb1171a732af7c807
commit r15-2857-g5ce3874b3c2fdd76f506005cb1171a732af7c807
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #15 from Richard Biener ---
The testcase is a bit unwieldly for developing a fix - I wonder if it's
possible to auto-generate smaller testcases with the same structure?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #14 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:634eae5ec3f3af2c4f6221d3ed2cf78d7f5c47f0
commit r15-2312-g634eae5ec3f3af2c4f6221d3ed2cf78d7f5c47f0
Author: Sam James
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #13 from Richard Biener ---
Most of the -O1 dom time is spent in threading using path ranger to simplify
the JT conditions. That in turn does (for each threading from scratch?)
GORI computes with most of the time spent in range_from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #12 from Richard Biener ---
At -O1 we have
Samples: 2M of event 'cycles:u', Event count (approx.): 2983686432518
Overhead Samples Command Shared Object Symbol
19.77%467950 cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #11 from Richard Biener ---
Btw, a question to the reporter - I suppose the files are machine-generated.
Are you able to create a file of smaller size? This one has ~20 lines,
some with 2000 and 2 lines would be perfect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #10 from Richard Biener ---
Created attachment 58505
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58505&action=edit
preprocessed testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #8 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #7)
> LOoks like the primary culprits now are:
>
> dominator optimization : 666.73 ( 7%) 0.77 ( 2%) 671.76 (
> 7%) 170M ( 4%)
> backwards jump t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #7 from Andrew Macleod ---
LOoks like the primary culprits now are:
dominator optimization : 666.73 ( 7%) 0.77 ( 2%) 671.76 ( 7%)
170M ( 4%)
backwards jump threading :7848.77 ( 85%) 21.04 ( 65%)7920.05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
Richard Biener changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #5 from jeremy rutman ---
Using gcc 14.0.1 20240117 (experimental) [master r14-8187-gb00be6f1576] I was
able to compile when not using any flags:
$ /usr/lib/gcc-snapshot/bin/cc -c aesDecrypt.c -o aesDecrypt.o
But when using the fla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
Richard Biener changed:
What|Removed |Added
CC||amacleod at redhat dot com
Ever co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #3 from jeremy rutman ---
For what it's worth, clang is able to compile the code in question.
Ubuntu clang version 18.1.3 (1)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #2 from Andrew Pinski ---
The code basically does a bunch of:
const SWord8 s599 = s557 ? s595 : s598;
const SWord8 s600 = s561 ? 14 : 246;
const SWord8 s601 = s561 ? 3 : 72;
const SWord8 s602 = s559 ? s600 : s601;
const SW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #1 from Andrew Pinski ---
Worthing noting on the trunk most of the compile time seems to be in the ranger
code ...
60 matches
Mail list logo
