This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [1/3] optabs: introduce {SET_,}{CONVERT_,}OPTAB_HANDLER

On 3 July 2010 23:48, Steven Bosscher <> wrote:
> On Sat, Jul 3, 2010 at 11:11 PM, Manuel López-Ibáñez
> <> wrote:
>> On 3 July 2010 23:07, Steven Bosscher <> wrote:
>>> On Sat, Jul 3, 2010 at 10:38 PM, Diego Novillo <> wrote:
>>>> On Saturday, July 3, 2010, Richard Sandiford <> wrote:
>>>>> I wondered about that, and not having a strong feeling either way,
>>>>> decided to stick with the current macro idiom. ?Can change if you like.
>>>> Yes, please. ?I would like to eliminate most of the function-like
>>>> macros we have. ?Let the inliner do its job and improve debuggability
>>>> by being able to set proper breakpoints.
>>> ... and force us to include headers that exposes things that should
>>> not be exposed. See e.g. all GIMPLE static inlines, which force us to
>>> expose the GIMPLE data structures also. And here the obtabs internals
>>> to files that only use obtabs.
>> Why would this be different when using macros?
> Nothing. Just a point against eliminating macros in favor of static
> inline functions in general.
> I'd argue for functions not static inline, in a .c file, and _really_
> let the inliner do its job (with WHOPR).

Then, the choice should be between functions and static inline
functions (I can see benefits of both), but never macros. It is also
easier to convert a static inline function to a function in a .c file.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]