New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Set default optimization level to -O1 #2411
Conversation
Don't merge this quite yet. There are a bunch of apparently new warnings due to inlining that will need to be dealt with. |
We are getting lots of warning from -Wunused-result and -Wmaybe-uninitialized. I'll see what I can do. |
Many false positives about unused variables caused by i.e., in:
gcc cannot figure out that the else block throws an exception, so it thinks that x may be uninitialized after the if-else block. Maybein the destructor of the MessageLogger class is inlined, we are good, but I'm not sure what implications that has for the destructor not being no-except. Very tricky issue. |
I'm not sure when I'll get around to fixing these warnings, unfortunately. If any C++ gurus want to take a stab at removing all warnings caused by -O1, say so, and I can make sure you have my latest code. |
I think it might be easier to just disable that check when compiling with
-O1. Some of the issues are in OpenFst and fixing those would be hard.
How about making the last options the following, and adding the comment
below
-g -O1 -Wno-maybe-uninitialized
# For more checking, add -DKALDI_PARANOID to the flags above.
# For faster compilation and easier debugging, remove -O1
-Wno-maybe-uninitialized
# For deployment and if you don't care about debugging, you could remove
-g and
# increase -O1 to -O2 or -O3.
…On Sat, May 19, 2018 at 11:55 PM, Daniel Galvez ***@***.***> wrote:
I'm not sure when I'll get around to fixing these warnings, unfortunately.
If any C++ gurus want to take a stab at removing all warnings caused by
-O1, say so, and I can make sure you have my latest code.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2411 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADJVu5A2eg4twrtsUwKz50LaAX4rI9IFks5t0OkigaJpZM4T5eNP>
.
|
since C++11, there is an attribute (i.e. standard attribute) `[[ noreturn
]]` that could be used in the MessageHandler to denote the function will
not return.
I assume we'd have to have two different versions of HandleMessage, say
HandleMessage and second HandleMessageNoReturn and call the latter one in
the KALDI_{ERR,ASSERT} macros
y.
…On Tue, May 15, 2018 at 6:34 PM Daniel Galvez ***@***.***> wrote:
Many false positives about unused variables caused by KALDI_ERR << "my
error message" not being interpreted by gcc as throwing an exception.
I'll see what I can do about this.
i.e., in:
int x;
if (condition) {
x = 2
} else {
KALDI_ERR << "something wrong"
}
gcc cannot figure out that the else block throws an exception, so it
thinks that x may be uninitialized after the if-else block. Maybein the
destructor of the MessageLogger class is inlined, we are good, but I'm not
sure what implications that has for the destructor not being no-except.
Very tricky issue.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2411 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKisX6B77mfw8it77UF_qpjmhIMHcHBhks5tywOVgaJpZM4T5eNP>
.
|
Actually, it might need probably even more careful refactoring, but perhaps
it would help in getting rid of some of the warnings, instead of just
turning the warnings off.
y.
…On Sun, May 20, 2018 at 8:39 AM Jan Trmal ***@***.***> wrote:
since C++11, there is an attribute (i.e. standard attribute) `[[ noreturn
]]` that could be used in the MessageHandler to denote the function will
not return.
I assume we'd have to have two different versions of HandleMessage, say
HandleMessage and second HandleMessageNoReturn and call the latter one in
the KALDI_{ERR,ASSERT} macros
y.
On Tue, May 15, 2018 at 6:34 PM Daniel Galvez ***@***.***>
wrote:
> Many false positives about unused variables caused by KALDI_ERR << "my
> error message" not being interpreted by gcc as throwing an exception.
> I'll see what I can do about this.
>
> i.e., in:
>
> int x;
> if (condition) {
> x = 2
> } else {
> KALDI_ERR << "something wrong"
> }
>
> gcc cannot figure out that the else block throws an exception, so it
> thinks that x may be uninitialized after the if-else block. Maybein the
> destructor of the MessageLogger class is inlined, we are good, but I'm not
> sure what implications that has for the destructor not being no-except.
> Very tricky issue.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#2411 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AKisX6B77mfw8it77UF_qpjmhIMHcHBhks5tywOVgaJpZM4T5eNP>
> .
>
|
@danpovey The openfst-related warnings can be removed by using -isystem,
instead of -I. See: https://stackoverflow.com/a/6321926/3469721
Thanks for the suggestion, @jtrmal. I was completely unaware of that!
…On Sat, May 19, 2018 at 11:42 PM, jtrmal ***@***.***> wrote:
Actually, it might need probably even more careful refactoring, but perhaps
it would help in getting rid of some of the warnings, instead of just
turning the warnings off.
y.
On Sun, May 20, 2018 at 8:39 AM Jan Trmal ***@***.***> wrote:
> since C++11, there is an attribute (i.e. standard attribute) `[[ noreturn
> ]]` that could be used in the MessageHandler to denote the function will
> not return.
> I assume we'd have to have two different versions of HandleMessage, say
> HandleMessage and second HandleMessageNoReturn and call the latter one in
> the KALDI_{ERR,ASSERT} macros
> y.
>
> On Tue, May 15, 2018 at 6:34 PM Daniel Galvez ***@***.***>
> wrote:
>
>> Many false positives about unused variables caused by KALDI_ERR << "my
>> error message" not being interpreted by gcc as throwing an exception.
>> I'll see what I can do about this.
>>
>> i.e., in:
>>
>> int x;
>> if (condition) {
>> x = 2
>> } else {
>> KALDI_ERR << "something wrong"
>> }
>>
>> gcc cannot figure out that the else block throws an exception, so it
>> thinks that x may be uninitialized after the if-else block. Maybein the
>> destructor of the MessageLogger class is inlined, we are good, but I'm
not
>> sure what implications that has for the destructor not being no-except.
>> Very tricky issue.
>>
>> —
>> You are receiving this because you are subscribed to this thread.
>> Reply to this email directly, view it on GitHub
>> <#2411 (comment)>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/AKisX6B77mfw8it77UF_
qpjmhIMHcHBhks5tywOVgaJpZM4T5eNP>
>> .
>>
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2411 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEi_UJer6ND0g-6R6F6oqOo0lCbCXmAMks5t0RBWgaJpZM4T5eNP>
.
--
Daniel Galvez
http://danielgalvez.me
https://github.com/galv
|
OK, I learned some new things.
The -isystem trick might not help on non-gcc compilers so I'm not sure how
much I want to rely on it.
And the [[noreturn]] thing is interesting too.
How about sub-classing MessageLogger, and having the destructor of the
error/assert versions marked [[noreturn]]?
On Sun, May 20, 2018 at 2:58 AM, Daniel Galvez <notifications@github.com>
wrote:
… @danpovey The openfst-related warnings can be removed by using -isystem,
instead of -I. See: https://stackoverflow.com/a/6321926/3469721
Thanks for the suggestion, @jtrmal. I was completely unaware of that!
On Sat, May 19, 2018 at 11:42 PM, jtrmal ***@***.***> wrote:
> Actually, it might need probably even more careful refactoring, but
perhaps
> it would help in getting rid of some of the warnings, instead of just
> turning the warnings off.
> y.
>
>
> On Sun, May 20, 2018 at 8:39 AM Jan Trmal ***@***.***> wrote:
>
> > since C++11, there is an attribute (i.e. standard attribute) `[[
noreturn
> > ]]` that could be used in the MessageHandler to denote the function
will
> > not return.
> > I assume we'd have to have two different versions of HandleMessage, say
> > HandleMessage and second HandleMessageNoReturn and call the latter one
in
> > the KALDI_{ERR,ASSERT} macros
> > y.
> >
> > On Tue, May 15, 2018 at 6:34 PM Daniel Galvez <
***@***.***>
> > wrote:
> >
> >> Many false positives about unused variables caused by KALDI_ERR << "my
> >> error message" not being interpreted by gcc as throwing an exception.
> >> I'll see what I can do about this.
> >>
> >> i.e., in:
> >>
> >> int x;
> >> if (condition) {
> >> x = 2
> >> } else {
> >> KALDI_ERR << "something wrong"
> >> }
> >>
> >> gcc cannot figure out that the else block throws an exception, so it
> >> thinks that x may be uninitialized after the if-else block. Maybein
the
> >> destructor of the MessageLogger class is inlined, we are good, but I'm
> not
> >> sure what implications that has for the destructor not being
no-except.
> >> Very tricky issue.
> >>
> >> —
> >> You are receiving this because you are subscribed to this thread.
> >> Reply to this email directly, view it on GitHub
> >> <#2411 (comment)
>,
> >> or mute the thread
> >> <https://github.com/notifications/unsubscribe-
auth/AKisX6B77mfw8it77UF_
> qpjmhIMHcHBhks5tywOVgaJpZM4T5eNP>
> >> .
> >>
> >
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#2411 (comment)>,
or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AEi_UJer6ND0g-
6R6F6oqOo0lCbCXmAMks5t0RBWgaJpZM4T5eNP>
> .
>
--
Daniel Galvez
http://danielgalvez.me
https://github.com/galv
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2411 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADJVu8uxDu5Bkhsmi6KFLcU4YNFC2YJ7ks5t0RQHgaJpZM4T5eNP>
.
|
@galv I'm trying to figure out something with travis -- could you push something into this branch? |
@galv nevermind, I closing/reopening the PR restarted the checks (which is what I wanted) |
Glad you figured it out.
…On Wed, Jun 13, 2018 at 8:48 AM, jtrmal ***@***.***> wrote:
@galv <https://github.com/galv> nevermind, I closing/reopening the PR
restarted the checks (which is what I wanted)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2411 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEi_UE1OBzuyRP4H0Y_dn449FkLsn0Lcks5t8TQygaJpZM4T5eNP>
.
--
Daniel Galvez
http://danielgalvez.me
https://github.com/galv
|
src/configure
Outdated
@@ -42,7 +42,7 @@ | |||
|
|||
# This should be incremented after any significant change to the configure | |||
# script, i.e. any change affecting kaldi.mk or the build system as a whole. | |||
CONFIGURE_VERSION=7 | |||
CONFIGURE_VERSION=8 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@galv, the configure version is already 8 now (and I don't know why the diff isn't vs. the master). Anyway-- I think if you just bump it up to 9, we should be good to go with this. Let's not overthink it.
Right, I remember Justin encountered this. Let me take a look at this again today, after I grab a late lunch. |
Previously, we were building at -O0 by default. Since gcc uses only the rightmost command line -O flag, override this by setting the environment variable EXTRA_CXXFLAGS.
We are getting way too many -Wmaybe-uninitialized-variable warnings because gcc does not realize that KALDI_ERR and KALDI_ASSERT do not return if we enable -O1. I need to either fix this As Yenda suggested, or maybe just add -Wno-maybe-uninitialized as a quick fix. |
Those maybe-uninitialized warnings can actually be useful sometimes.
One possibility is this:
the compiler can't realize the destructor of MessageLogger exits because
it's defined in the .cc file. We could leave it there but have a
sub-class of MessageLogger called ErrorLogger, that is the same as
MessageLogger, but its destructor is inlined and calls exit(1). That code
would never be reached, but would let the compiler know.
BTW there are some ifdefs, around KALDI_NOEXCEPT, in kaldi-error.h that are
no longer needed I think now that we require c++11.
Daniel, could you try this ASAP?
…On Sat, Aug 25, 2018 at 10:58 AM Daniel Galvez ***@***.***> wrote:
We are getting way too many -Wmaybe-uninitialized-variable warnings
because gcc does not realize that KALDI_ERR and KALDI_ASSERT do not return
if we enable -O1. I need to either fix this As Yenda suggested, or maybe
just add -Wno-maybe-uninitialized as a quick fix.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2411 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADJVuzFp_P-IVhLl__xNMCeai9ACbbI-ks5uUZBWgaJpZM4T5eNP>
.
|
These were caused by compiler not realizing that KALDI_ERR and KALDI_ASSERT don't return. Solution came from suggestions by Yenda, Dan Povey, and the GLOG library. Still needs to be cleaned up a little bit.
It is possible that the two GetVerboseLogs() may return different values, because the global verbosity varible could change.
7e41e43
to
ab6a0c5
Compare
I've figured something out. See my latest commits if you are curious. It's inspired by the google logging library, which faced the same problem. It's not totally polished yet. I'll see if I can clear time in my day tomorrow to clean this up and finish this of. |
fl = si/(float)(4*256); | ||
syn_d[aa] = fl;*/ | ||
} | ||
} | ||
|
||
saveWeights(); | ||
|
||
// idiom to "use" an unused variable | ||
(void) unused_size; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you might be able to achieve the same thing by declaration
volatile in unused;
but your solution might be better (could get optimized better), however at the cost that you have remember to "use" the unused variable in each path through the code.
great, makes sense to me
y.
…On Mon, Aug 27, 2018 at 12:22 PM Daniel Galvez ***@***.***> wrote:
I've figured something out. See my latest commits if you are curious. It's
inspired by the google logging library, which faced the same problem. It's
not totally polished yet. I'll see if I can clear time in my day tomorrow
to clean this up and finish this of.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#2411 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKisX_uIGkUOKp73dpZnRdr4naefQMaKks5uU5dAgaJpZM4T5eNP>
.
|
i found the reason for test failure--- was unrelated I think. will merge. |
@danpovey Could I kindly ask you to revert this merge? I just finished removing all of the warnings generated at -O1 last night, but I did not push it because I had plans that night and wanted to look it over one last time. I apologize, but I may not have communicated to you clearly how many warnings that this change will produce when kaldi is compiled (feel free to check for yourself). |
Check out my most recent push on my personal branch to see the extent to which I had to change files to silence extraneous warnings: galv@57a0bee I am running tests now to make sure that I haven't broken anything, but the tests themselves also generate new warnings, so I will need to silence the warnings in those too. I don't think this is ready yet. |
If it wasn't broken and just generates a lot of warnings, I'd prefer to
leave it merged. Some warnings are OK, esp. for a short time. We can fix
it later.
…On Wed, Aug 29, 2018 at 3:12 PM Daniel Galvez ***@***.***> wrote:
Check out my most recent push on my personal branch to see the extent to
which I had to change files to silence extraneous warnings: ***@***.***
<galv@57a0bee>
I am running tests now to make sure that I haven't broken anything, but
the tests themselves also generate new warnings, so I will need to silence
the warnings in those too.
I don't think this is ready yet.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2411 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADJVu0qyt34YN1s3xGJ1fhjhRXOXyMPKks5uVueOgaJpZM4T5eNP>
.
|
Okay, well, I guess it's an incentive for me to actually get this done quickly then. |
I wonder if you could also add explicit -fno-fast-math with a comment that enabling fast-math leads to improper handling of NaN and Inf (in the IEEE754 sense) and kaldi will not function properly in that case? |
I suppose the question is whether -fno-fast-math disables those
optimizations if you later specify -Ofast. If not, I don't see that
it would add much value.
…On Fri, Aug 31, 2018 at 8:54 AM jtrmal ***@***.***> wrote:
I wonder if you could also add explicit -fno-fast-math with a comment that enabling fast-math leads to improper handling of NaN and Inf (in the IEEE754 sense) and kaldi will not function properly in that case?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I think it's a matter of position, so if you specify Ofast or ffast-math
after fno-fast-math, then it gets overridden, as you said.
Y.
…On Fri, Aug 31, 2018, 21:59 Daniel Povey ***@***.***> wrote:
I suppose the question is whether -fno-fast-math disables those
optimizations if you later specify -Ofast. If not, I don't see that
it would add much value.
On Fri, Aug 31, 2018 at 8:54 AM jtrmal ***@***.***> wrote:
>
> I wonder if you could also add explicit -fno-fast-math with a comment
that enabling fast-math leads to improper handling of NaN and Inf (in the
IEEE754 sense) and kaldi will not function properly in that case?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#2411 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKisX6wVMYce-HNBmvleOOa_D55opyibks5uWWR6gaJpZM4T5eNP>
.
|
Previously, we were building at -O0 by default.
Since gcc uses only the rightmost command line -O flag, override this
by setting the environment variable EXTRA_CXXFLAGS.