Correct, I am unsure whether gcc does any sort of static re-use analysis or
not. I was just getting the feeling that you were saying that GCC doesn't
do any sort of whole-program analysis and wanted to clarify that part.
On Thu, May 23, 2013 at 2:41 AM, David Brown <da...@westcontrol.com> wrote:
> On 22/05/13 19:30, Alex Orange wrote:
> > Isn't that exactly what LTO of the new GCC versions does. I have no idea
> > whether mspgcc supports it, though I would guess it might. My
> understanding
> > is that GCC LTO works by just storing the GIMPLE trees in the object
> files,
> > stitching them together at link time and generating code from the
> stitched
> > GIMPLE tree instead of regular linking. Of course there's some complexity
> > in there, but it might be independent of the machine specific code.
>
>
> That is pretty much how LTO works (though it is more complex these days,
> in order to be scalable for large code bases). I haven't tried it
> myself as yet - it can make debugging somewhat more "interesting".
>
> However, that does not imply that gcc does any sort of analysis for
> re-use of static data according to when the data in them is /actually/
> used. It is very difficult to determine when statically allocated data
> is no longer needed - and can thus be re-used by something else. Even
> compilers that do re-use global data limit this mainly to data that is
> logically local (local variables, parameters, etc.) that are placed in
> global areas due to poor stack support on the cpu.
>
>
> >
> >
> > On Wed, May 15, 2013 at 5:15 AM, David Brown <da...@westcontrol.com>
> wrote:
> >
> >> On 15/05/13 08:30, A.P. Horst wrote:
> >>>
> >>> On 15-5-2013 0:31, Paul Sokolovsky wrote:
> >>>> Hello,
> >>>>
> >>>> On Wed, 15 May 2013 09:35:14 +1200
> >>>> Daniel Beer <dlb...@gmail.com> wrote:
> >>>>
> >>>>> On Tue, May 14, 2013 at 09:26:46PM +0300, Paul Sokolovsky wrote:
> >>>>>> More interesting question is such support for static (if not global)
> >>>>>> variables. When trying to do Elliptic Curve Cryptography on MSP430
> >>>>>> value line devices which top up at 0.5K RAM, you really wish that
> >>>>>> compiler could "pack" together static buffers of functions which
> >>>>>> cannot be active at the same time ;-). If anyone know of that to be
> >>>>>> done by gcc, would be nice to get some pointers.
> >>>>> If you have static buffers which are never in use simultaneously, why
> >>>>> not keep them together in a union { }?
> >>>> Yes, the talk was about offloading the work of proving
> >>>> non-simultaneous access constraints and creation of that union to the
> >>>> compiler ;-). Shouldn't be hard for the case of scalar static
> variables
> >>>> (function-local dataflow analysis and interprocedural control flow
> >>>> analysis), so I wondered if someone knows it to be implemented. To be
> >>>> really useful this should be applied to structural/array vars though,
> >>>> and that's much harder.
> >>>>
> >>>
> >>> This would be absolutely impossible because the compiler is generally
> >>> unaware of it's environment. If the application is run on a preemptive
> >>> scheduling operating system, then such schemes could go horribly wrong.
> >>> Of course, you could protect the memory with a mutex, but this would
> >>> defeat the purpose of easy optimization. Anyway, if you really want it
> I
> >>> think it is best done via an explicit way with unions such that it is
> >>> clear what is being shared, and it compatible amongst compilers.
> >>>
> >>> Arie
> >>>
> >>
> >> The general case is impossible (since it reduces to the halting
> >> problem), and even without pre-emption it is impractical to get optimal
> >> results (since it would take exponential time). However, for many
> >> practical situations it /is/ possible to do quite a good job. In
> >> particular, whole-program optimisation and heavy use of "static" can
> >> help the compiler determine when different variables are in use.
> >>
> >> gcc does not do this sort of analysis and global data reuse, but some
> >> embedded compilers /do/. In particular, some of the more high-end
> >> compilers for very small microcontrollers (Keil's 8051 compiler and
> >> ByteCraft's compilers being examples) do exactly this sort of analysis.
> >> For these chips, stacks are impractical due to the lack of useful
> >> addressing modes, so function parameters, return values, and local
> >> variables all end up in fixed locations in ram (unless functions are
> >> re-entrant - in which case a stack is needed giving a huge performance
> >> hit). This sort of global lifetime analysis is essential to reduce the
> >> ram usage.
> >>
> >> For more general code on more sensible processors, such as the msp430,
> >> it would be hard to make such analysis algorithms that always work, run
> >> in a sensible amount of time, and give you a significant benefit for the
> >> effort.
> >>
>
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
