search for: sidetables

...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 t...

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

...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 general...

...ckend 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 low...

On Thu, Aug 13, 2020 at 4:38 PM Haoran Xu <haoranxu510 at gmail.com> wrote: > > Hello David and Sterling, thanks for the reply! > > I have no intention to heat up the discussion, please pardon me if I asked questions that might sound silly to you -- it's just that I truly didn't understand since I'm not expert in llvm or optimizer or exception handling at all. >

On Thu, Aug 13, 2020 at 6:11 PM Haoran Xu <haoranxu510 at gmail.com> wrote: > > Thanks for the insights David! > > For your first 3 points, is it correct to understand it as following: the external function prototypes are missing reliable information on whether the function throws and what exceptions it may throw (due to C++'s design failures and that it is impractical to

On Thu, Aug 13, 2020 at 6:35 PM Haoran Xu <haoranxu510 at gmail.com> wrote: > > Thanks for the reply. > >> Sorry, yes. No difference between explicit error handling and >> exceptions. The difference is in all the functions that don't have >> explicit error handling but (in the exception-using equivalent code) >> aren't marked nothrow (where, without

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