Bug 590727 - var tracking issues with various kde applications
Summary: var tracking issues with various kde applications
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc   
(Show other bugs)
Version: 13
Hardware: All Linux
low
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-10 14:57 UTC by Rex Dieter
Modified: 2010-05-10 15:22 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-10 15:17:33 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Rex Dieter 2010-05-10 14:57:19 UTC
Symptoms similar to past issues like bug #538233 seem to have resurfaced lately, on my own box, I see this trying to build both kdepim and konversation

$ rpm -q gcc
gcc-4.4.4-2.fc13.x86_64

I compared past and recent build-times in koji, and these don't seem to vary much, so maybe it's something particular to my own box that has updates-testing enabled.

I'll keep digging for reproducers in the meantime.

Comment 1 Jakub Jelinek 2010-05-10 15:11:55 UTC
You need to be more factual, on which sources, what g++ command line options, attach preprocessed sources.  And, how long is too slow (for the insanely huge routines KDE uses so much)?  Is the var-tracking limit reached or not?

The generated debug info quality increased quite a lot over the last few months
and in some cases it means more values tracked in var-tracking, which on these several thousand basic blocks long functions isn't exactly cheap.

Comment 2 Rex Dieter 2010-05-10 15:16:23 UTC
OK, it seems to take a little while for problematic files, but not nearly as bad as it was previously.

For example, konversation now takes ~5 minutes longer (on a fast builder) than when using -fno-var-tracking-assignments

Comment 3 Rex Dieter 2010-05-10 15:17:33 UTC
I'll do some more tests, but these slightly longer times seems to be acceptable for the extra work being done.  so, consider it not an issue unless I find something 'really bad'(tm)

Comment 4 Jakub Jelinek 2010-05-10 15:22:32 UTC
We definitely intend to work on var-tracking speed improvements (especially Alex Oliva), on the other side have several big projects which severely improve debug info quality at the expense of tracking yet more stuff.
~5 minutes longer compilation on huge functions is bad, but not extremely high priority - that would be for something taking hours to build or eating way too much memory or a significant slowdown across large codebase.


Note You need to log in before you can comment on or make changes to this bug.