This is the mail archive of the gcc-patches@gcc.gnu.org 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 Sat, Jul 3, 2010 at 11:11 PM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 3 July 2010 23:07, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
>> On Sat, Jul 3, 2010 at 10:38 PM, Diego Novillo <dnovillo@google.com> wrote:
>>> On Saturday, July 3, 2010, Richard Sandiford <rdsandiford@googlemail.com> 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).

Ciao!
Steven


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