Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1561996

Re: alpha: Checking source code positions for the setting of error codes

Show all headers | View raw

On Wed, Jan 18, 2017 at 04:41:10PM +0100, SF Markus Elfring wrote:
> >> A local variable was set to an error code in two cases before a concrete
> >> error situation was detected. Thus move the corresponding assignment into
> >> an if branch to indicate a software failure there.
> >>
> >> This issue was detected by using the Coccinelle software.
> > 
> > Why the hell is that an issue?
> 
> * Can misplaced variable assignments result in unwanted run time consequences
>   because of the previous approach for a control flow specification?

More like the opposite.
	load constant to register
	test
	branch usually not taken
is considerably cheaper than
	test
	branch usually taken

Something like
	if (unlikely(foo)) {
		err = -ESOMETHING;
		goto sod_off;
	}
would be more or less on par (and quite possibly would be compiled into
the same code - depends upon the scheduling details for processor,
but speculative load of constant can be an optimization).  However, that
has an effect of splattering the source with tons of those unlikely() *and*
visually cluttering the common path.

> * How do you think about to achieve that error codes will only be set
>   after a specific software failure was detected?

Sounds like an arbitrary requirement, TBH...

Again, loading a constant into register tends to be cheap and easy to
combine with other instructions at CPU pipeline level.  If anything, this
pattern is a microoptimization, often in spots that are not on hotpaths
by any stretch of imagination.  But estimating whether a given place is
on a hot path takes a lot more delicate analysis than feasible for
cocci scripts.  And visual cluttering of the common execution path remains -
it doesn't matter for compiler, but it can matter a lot for human readers.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH 0/4] alpha: Fine-tuning for five function implementations SF Markus Elfring <elfring@users.sourceforge.net> - 2017-01-18 12:50 +0100
  [PATCH 4/4] alpha: Move two assignments for the variable "res" in  srm_env_proc_write() SF Markus Elfring <elfring@users.sourceforge.net> - 2017-01-18 13:00 +0100
    Re: [PATCH 4/4] alpha: Move two assignments for the variable "res"  in srm_env_proc_write() Jan-Benedict Glaw <jbglaw@lug-owl.de> - 2017-01-18 14:40 +0100
      Re: [PATCH 4/4] alpha: Move two assignments for the variable "res" in  srm_env_proc_write() SF Markus Elfring <elfring@users.sourceforge.net> - 2017-01-18 15:30 +0100
    Re: [PATCH 4/4] alpha: Move two assignments for the variable "res"  in srm_env_proc_write() Al Viro <viro@ZenIV.linux.org.uk> - 2017-01-18 15:20 +0100
      Re: alpha: Checking source code positions for the setting of error  codes SF Markus Elfring <elfring@users.sourceforge.net> - 2017-01-18 17:00 +0100
        Re: alpha: Checking source code positions for the setting of error  codes Al Viro <viro@ZenIV.linux.org.uk> - 2017-01-18 18:50 +0100
    Re: [PATCH 4/4] alpha: Move two assignments for the variable "res"  in srm_env_proc_write() kbuild test robot <lkp@intel.com> - 2017-01-19 01:50 +0100
  [PATCH 3/4] alpha: Return directly after a failed copy_from_user() or  getname() in two functions SF Markus Elfring <elfring@users.sourceforge.net> - 2017-01-18 13:00 +0100
  [PATCH 2/4] alpha: Move two assignments for the variable "error" in  osf_utsname() SF Markus Elfring <elfring@users.sourceforge.net> - 2017-01-18 13:00 +0100

csiph-web