From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753379AbcAOQZX (ORCPT ); Fri, 15 Jan 2016 11:25:23 -0500 Received: from mout.web.de ([212.227.17.12]:55472 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752490AbcAOQZR (ORCPT ); Fri, 15 Jan 2016 11:25:17 -0500 Subject: Re: InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions To: linux-rdma@vger.kernel.org, Leon Romanovsky References: <566ABCD9.1060404@users.sourceforge.net> <567EDED5.4040201@users.sourceforge.net> <5697D865.5010507@users.sourceforge.net> <5697DE31.9040309@users.sourceforge.net> <20160115132014.GC30615@leon.nu> <56990733.7000506@users.sourceforge.net> <20160115150935.GA32346@leon.nu> <56990FAC.6000506@users.sourceforge.net> <20160115155938.GB32346@leon.nu> Cc: Devesh Sharma , Doug Ledford , Hal Rosenstock , Mitesh Ahuja , Sean Hefty , Selvin Xavier , LKML , kernel-janitors@vger.kernel.org, Julia Lawall From: SF Markus Elfring X-Enigmail-Draft-Status: N1110 Message-ID: <56991D52.8030808@users.sourceforge.net> Date: Fri, 15 Jan 2016 17:24:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160115155938.GB32346@leon.nu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:VBhV7tSzqcKe5wRboy0OU6ijII4TXJ7VC3ZeMa3YTygGr6XZyBT LBcZabzfdwDmUHPgT8ulk5lYxZL6EOV2Kq2GyM7qwYxN1qo7NAGroaIGkJIY5Gd5vE7R/AX mhV3VmyfirAe4qQCstcA6JOi8RYMBWGMKAVQMUnlCoYbALP2BN7DqRvzC+Jof6pyrl1wxSY aw547L+IS1YaH9ctux4qg== X-UI-Out-Filterresults: notjunk:1;V01:K0:K/m54QQf82Q=:rEk7ourYLHh1fgnPACpYzu ul0OzpF08dtLtj5hGU/oR1uihd2O23VbJTCkZ9L4w1LkxbSG7TYVnZQAkx4DiV2hPXpfe2wtg setHT71G8JMxnBC1shxPhUTxX06XC4C6caDySu9KBgq28UYRsI7byh+WozG0OiFN+wVZ/BEbH rpnp8V+zQN3sTbJJfQEfcw1E15PH35Uc7dd4bWYX69l7HWgtr5lt0jtngnrKVvprBx2NjZDcD j5v1NjWN7Uan3LRpi1KJo8fdmtYaLkTs/j4ws8kzvBlCRvBE/357E1mROmBHf1kf44u9SsEH5 gpBzAapLZ5Mh/+OvR045BkxtMTAWNUVhSAT+0tGq6yvrebCiyfZb+TEfb+CJfz7DsgC7MAvXK UDYlXFNlypSiRYnpKSG3NgzYagMR7GA2iRwT3VBAL1ss8VUn1InEuIuKIAZ3J70QlQhip4PIJ /PEv+KMRoMSI67TjH3/BociZZD1ytPpMEmzz1XLSIMdwFB4oVtdgMWkAIxESVoZeNayEy6Iuq ztM3nFILuI6ybyyeR16mhLRcFelzNVtFsu9POUq75oN7oIykm2Q1ruAHvzjt/wCA1pYFIeYDg BrYVroyjjaTyT1sk/vGSoC0kUypNIVUSvp9UP39hwfLYl0tJTSN5YWflYYRAdPQsSDyOIKaN+ GLgITWJ0K2e66LyQVKl/1HnL4Gqbd9ovN1oqehmgysl7RuI7cWxegenrtR3K96sa5XfVdbuR4 1IxolKcDIClEopJ1MC6/bsIEWZ8NIHxfc/4CEGVVBwouzMqonxckgTEF55G2BDey0I5SKpIkF VEbEGay Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > GCC supported it before 1999 when I saw it first time. My assumption > that in 2016 all compilers are doing such optimization now. Interesting … > I would be glad to hear an example of modern compiler which doesn't > support this simple optimization. Would you like to take into account any other source code analysis approaches? >> Will any configuration parameters and command arguments become relevant >> to improve also a corresponding software comparison? > > Please suggest us, you are proposing this change, and not me. Which combination of hardware and software versions would you find representative for a corresponding system check? >>> The proposed change won't affect performance at all. >> >> Will unneeded variable assignments be really optimised away by default? > > Yes Can it be that this result will depend on special parameters so that data flow analysis and optimisation will be performed in the way you seem to expect? > If you are interested in saving space of one latter, you need to take into > account git database increase, do you? There are also other aspects to consider: * Do you insist to initialise a return code at the beginning of every function with a non-void return type? * Does each bit of extra information can result also in unwanted consequences? * Is this a specific source code review concern? * Can this software be improved a bit more only if we dare to talk about potential update candidates? Regards, Markus