[PATCH] var-tracking.c: Fix possible use of uninitialized variable pre

[Andreas Krebbel]

On 30.04.20 18:33, Richard Biener wrote:
> On Thu, Apr 30, 2020 at 5:14 PM Andreas Krebbel <krebbel@linux.ibm.com> wrote:
>>
>> On 30.04.20 08:25, Richard Biener via Gcc-patches wrote:
>>> On Wed, Apr 29, 2020 at 5:56 PM Jeff Law <law@redhat.com> wrote:
>>>>
>>>> On Tue, 2020-04-28 at 11:44 +0200, Richard Biener via Gcc-patches wrote:
>>>>>
>>>>> Btw, does s390 have different inlining parameters somehow?
>>>> I think so.  We saw a ton of backend warnings that were specific to the s390
>>>> builds in Fedora that appeared to be triggered by different inlining decisions.
>>>>
>>>> It happened enough that one of the ideas we're going to explore is seeing if we
>>>> can tune the x86_64 port to use the same heuristics.  That way we can try to find
>>>> more of these issues in our tester without having to dramatically increase s390x
>>>> resourcing.  This hasn't started, but I expect we'll be looking at it in the fall
>>>> (it's unclear if we can just use flags or will need hackery to the x86 port, but
>>>> we're happy to share whatever we find with the wider community).
>>>
>>> Hmm, OK.  Guess if it becomes an issue for openSUSE I'll simply revert those
>>> s390 backend changes.
>>
>> Too bad. I would prefer to fix the root cause of the warnings instead. Isn't it a good thing that
>> thanks to the more aggressive inlining actual bugs in the code get revealed? Or do you see other
>> issues with that?
> 
> I'm obviously more concerned about latent GCC issues only popping up
> on s390.  Basically
> the s390 limits throw much of the QA done on x86_64 targets away when
> comparing to s390.
That's indeed a problem. It isn't only about GCC itself. We also see more bugs in distro packages
revealed on s390.  But in the end these often are actual bugs and should be fixed one way or the
other. Wouldn't it be better to find more of these bugs upfront?

Would it perhaps make sense to introduce an optimization level which tries to maximize the number of
warnings produced? I know this might be tricky since some optimizations tend to produce a certain
set of warnings while reducing warnings in another area at the same time. But still I think there
would be some value in picking extreme params with that option and have it consistent across archs.

> For example we do burn-in testing of a new GCC release (10.1 here) in
> openSUSE Factory
> by using it as system compiler.  Then with GCC 10.2 we ship it as
> compiler for their own use
> to SLES users and ISVs.  But obviously all the burn-in testing on
> openSUSE Factory
> is very x86_64 centric these days.
I think Matthias is doing this with Ubuntu also for other archs. Thanks to him we are usually able
to fix a bunch of problems beforehand. Kudos to him for doing that!

>>>
>>> As a general advice to backend developers I _strongly_ discourage to adjust
>>> --param defaults that affect GIMPLE.
>>
>> We did tons of measurements to find these values recently and got a nice speedup after increasing
>> them. We also had a look at the size increase of binaries. It was significant but we decided that
>> the performance benefit is worth it. On IBM Z the function call overhead is bigger than on other
>> archs so inlining in general helps us.
>>
>> I'm not sure I understand your recommendation to leave these values as is. I assumed that such
>> parameters are supposed to be used to deal with the characteristics of a platform. Are there better
>> ways to achieve the same effect?
> 
> Get more inlining than other archs?  No, I don't think so.  But if the
> call overhead is bigger then
> you should adjust the cost of calls instead?  
Is there a dedicated knob for adjusting call costs? We played with branch-costs in the past but this
is not dedicated to just calls. Increasing it usually had negative effects for our target, although
we might need to re-iterate on that one as well.

> Also the default limits
> are a delicate compromise
> between speed and size - of course if you disregard size you get more
> speed.  You also only
> adjusted two out of very many params which are not really as
> independent as one would think...
> (and you forgot to re-tune after last years big changes/parameter space splits).
Oh, we set other inlining params as well. It is just that with z13 we tuned in particular also for
these two. Since we don't have measurements on other CPU levels we didn't want to risk producing
regressions and just have left the values as is for those.

> As said you should at least think of adjusting the adjustments to be
> relative to the default
> value rather than absolute.
Ok.

Andreas
> 
> Richard.
> 
>> Andreas
>>
>>>
>>> Richard.
>>>
>>>> jeff
>>>>
>>>>
>>>>
>>