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

Groups > comp.std.c > #6012

Re: register at file scope

Show all headers | View raw

Am 28.10.19 um 15:28 schrieb David Brown:
> 
> You can easily achieve that in C today by storing *p in a local variable:
> 
> void f(int *p)
> {
>   int x = *p;
>   if(i <= x)
> 	i = x + 1;
> 
>   if (x & 0xa5)
>     …
> }

Yes, but it somtimes makes the code less readable, especially, if
multiple pointers / arrays are involved

> 
> You can also make p "restrict".

In this simple case yes. But in real-worls examples there can be
multiple pointers and some of them might indeed be allowed to point to
the same memory.

> 
> And, again, you could make "i" static to the file - something that is
> generally considered good style anyway.
> 

Obviously variables at file scope are _not_ declared static, when they
are indeed accessed from other translation units.
That might not be considered good style, but is still very common when
programming embedded systems..

> 
> So we are talking about a rather minor improvement to rare uses in code
> where the same efficiency can be achieved in other ways without
> significant effort.  I don't see that being good enough to justify
> modifying a keyword that is, I believe, more likely to be deprecated
> than expanded.

Better alias analysis can help with many optimizations. Use of global
variables is still common in small embedded systems - in some ways the
dveices, where optimization matters the most, due to tight memory,
energy and runtime constraints.

> 
> If you could argue a significant benefit to code safety, I'd be a lot
> more supportive.
> 

My motivation is optimization. By giving hte compiler morre information,
which of course, can also be used for diagnostics.

> 
>>>
>>> Remember also that the trend in optimising compilers is towards cross-TU
>>> information exchange and optimisation (link-time optimisation,
>>> whole-program optimisation, omniscient compilation, and various other
>>> terms).  Such cross-unit information exchange and optimisation provides
>>> improvements that subsume your suggestion here, and provide vastly more
>>> benefits in addition.
>>>
>>
>> While LLVM is going that way, there is a large number of C
>> implementations (most timplementations tagret some small embedded
>> systems) out there, most of which probably don't have the manpower to
>> switch to whole-program optimization. There are still implementations
>> that work a function at a time, not even taking full advantage of static.
>>
> 
> For the compilers with limited optimisation, the issue is irrelevant
> anyway - they are not going to support optimisations allowed by this
> enhancement when there are huge areas of improvement open already.
> 
> Whole-program optimisation has been available in the embedded world from
> before LLVM was started.  It is used in the top range (and top price)
> compilers from folks like IAR, ByteCraft and Keil.  It has also been
> available in more limited ways from other compilers for a long time -
> gcc has had "-fwhole-program" for a good many years.
> 
> The embedded toolchain arena is divided into four groups.  There is the
> "cheap and cheerful" group, where ease of use and customer service are
> prioritised far higher than optimal code generation.  Such tools will
> not support a change like this - many barely support C99.  And they
> won't support the optimisations it makes available anyway.
> 
> There are legacy compilers, or limited compilers for legacy devices -
> clearly these will not support a new feature.
> 
> There are the top-end compilers - these support whole-program
> optimisation, and have no need of such enhancements.
> 
> And then there is gcc (along with a small proportion of clang usage),
> which also supports whole-program optimisations for those that are
> aiming for the very best efficiency.
> 

Where would SDCC fit into your picture?

> 
> I simply don't see a significant area of toolchain suppliers that would
> be able to generate more efficient code with this feature, and which
> would actually do so if this feature were standardised.  And thus I also
> don't see a significant user-base for the feature.
> 
> If there are compilers for which it might be useful, I think they would
> be better served with a compiler extension for the purpose.

Introducing this as a compiler extension first and also evaluate the
impact of placing register in appropriate places in some real-world code
or a benchmark would indeed make sense.

Philipp

Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

register at file scope Philipp Klaus Krause <pkk@spth.de> - 2019-10-25 12:45 +0200
  Re: register at file scope David Brown <david.brown@hesbynett.no> - 2019-10-26 17:33 +0200
    Re: register at file scope Philipp Klaus Krause <pkk@spth.de> - 2019-10-26 19:24 +0200
      Re: register at file scope David Brown <david.brown@hesbynett.no> - 2019-10-27 12:39 +0100
        Re: register at file scope Philipp Klaus Krause <pkk@spth.de> - 2019-10-28 12:22 +0100
          Re: register at file scope David Brown <david.brown@hesbynett.no> - 2019-10-28 15:28 +0100
            Re: register at file scope Philipp Klaus Krause <pkk@spth.de> - 2019-10-29 10:00 +0100
              Re: register at file scope David Brown <david.brown@hesbynett.no> - 2019-10-29 13:46 +0100
              Re: register at file scope Philipp Klaus Krause <pkk@spth.de> - 2019-11-25 12:19 +0100

csiph-web