Nicholas Clark <[EMAIL PROTECTED]> wrote: > I was wondering whether it would be feasible to replace macros (some, most > or even all) conditionally with inline functions if the inline keyword is > available.
AFAIK the only place where macros are widely used is jit_emit.h. I'm not aware of other macros that could be inline functions. Changing jit_emit.h isn't worth the effort, there isn't much debugging necessary for the emit code. The macros inside pobj.h can go away, when the layout of PMCs doesn't change anymore. > But: > 1: I'm not sure how easy this is logistically. We'd have to have some way > of munging the C source to give one or the other When you have to provide both function and macro versions it'll clutter source code. Doing it with kind of a pre-processor probably makes more sense then, OTOH this complicates the build process. > 2: I'm not sure if inline functions have any downsides compared with macros, > such as not always giving as good optimisations as macro-re-written code. Not AFAIK. When carefully, selected inlined functions are as effective as macros. OTOH automatically inlined functions can slow down the code (-O3, i386, gcc 2.95.2). Benchmarking and looking at the generated code helps. > Is this something worth taking further? Sure. E.g. perlscalar.pmc:morph() comes to my mind. It was a macro some time ago and really should be inlined. OTOH its still a bit early to start such optimizations at code level. We first have to look at overall structure and algorithms. > (Ulterior motive - I'm curious whether doing this would also help perl 5) If you are trying to debug some deeply macroized piece of ocde, it probably makes sense to rewrite it to an inlined function first. But I wouldn't know, where to start ... > Nicholas Clark leo
