search for: sidetable

...gt; it would simpler to implement in the backend though and this approach > would need changes to the frontend, so a lot more work. The backend already can sort of do this with the GCMetadataPrinter. Generalizing that to arbitrary side tables might be easier than adding a new construct (granted sidetables might not replace the ability to output assembly by that class, but they might do a lot of the heavy lifting). Since GC lowering happens on the IR level (from the docs I looked at, I haven't personally dealt with GC yet), it maybe possible to do a lot of lowering to generalized tables rather...

Its good to see that a feature of this nature would be useful to a whole range of people, I wasn't aware of that. On 9 June 2010 22:40, Andrew Lenharth <andrewl at lenharth.org> wrote: > My argument amounts to express side tables as side tables in the IR > rather than as an ordering on globals.  I think that would simplify > the backend (a side table is something you discover

...sections. http://sourceware.org/binutils/docs-2.20/as/Sub_002dSections.html#Sub_002dSections The way this works is that you can put stuff into a section like '.text 2', where 2 is a subsection of .text When run, 'as' orders the subsections. So all you need to do is arrange for the sidetable to be in section '.text n' and the code in section '.text n+1'. Each sidetable and its code goes in its own subsection. The nice thing is, this is purely a gnu as feature. When it compiles the assembly to object code, the subsections aren't present in the object code, so you don...

...ourceware.org/binutils/docs-2.20/as/Sub_002dSections.html#Sub_002dSections > > The way this works is that you can put stuff into a section like > '.text 2', where 2 is a subsection of .text When run, 'as' orders the > subsections. So all you need to do is arrange for the sidetable to be > in section '.text n' and the code in section '.text n+1'. Each > sidetable and its code goes in its own subsection. The nice thing is, > this is purely a gnu as feature. When it compiles the assembly to > object code, the subsections aren't present in the obj...

...opagation depending on profiles or other things. Yes, with a full ABI break you could have a completely different exception handling scheme that doesn't use tables at all - adds an extra implicit return value from every function call wvhich is the "did this throw" bit, with some other sidetable of the actual data that was thrown, etc - I believe this is the sort of model Swift uses, for instance. But that has a different set of performance tradeoffs (& again, the defaults are problematic - C++ compilers must assume all functions throw unless annotated otherwise, and C++ writers don...

...ther >> things. Yes, with a full ABI break you could have a completely >> different exception handling scheme that doesn't use tables at all - >> adds an extra implicit return value from every function call wvhich is >> the "did this throw" bit, with some other sidetable of the actual data >> that was thrown, etc - I believe this is the sort of model Swift uses, >> for instance. But that has a different set of performance tradeoffs (& >> again, the defaults are problematic - C++ compilers must assume all >> functions throw unless annotat...

...with a full ABI break you could have a completely >> >> different exception handling scheme that doesn't use tables at all - >> >> adds an extra implicit return value from every function call wvhich is >> >> the "did this throw" bit, with some other sidetable of the actual data >> >> that was thrown, etc - I believe this is the sort of model Swift uses, >> >> for instance. But that has a different set of performance tradeoffs (& >> >> again, the defaults are problematic - C++ compilers must assume all >> &gt...

There is a fair amount of dispute and detail here, and real benchmarks can be difficult to write, because you often end up in arguments about whether or not the two styles of coding are equivalent or not. But I agree with Dave--exceptions generally inhibit optimization. One way to think about this is that, generally speaking, the less the compiler can prove about a program, the less aggressive