This is the mail archive of the gcc@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: Normalizing the bitmap APIs.


On Thu, Oct 11, 2012 at 11:57 PM, Diego Novillo <dnovillo@google.com> wrote:
> On 2012-10-11 16:25 , Lawrence Crowl wrote:
>>
>> On 10/11/12, Diego Novillo <dnovillo@google.com> wrote:
>>>
>>> On 2012-10-11 13:26 , Lawrence Crowl wrote:
>>>>
>>>> My only other concern was that the mapping between those function
>>>> names and the tasks to be done sometimes seemed less than obvious.
>>>> So, I proposed the name change.  However, I think the current names
>>>> are workable, assuming an acceptable solution to the above problem.
>>>
>>>
>>> I would say, add both variants and make the empty ones drop the return
>>> value.  So, for instance, bitmap_ior returns a value, so make
>>> bitmap_ior_cg drop it.
>>
>>
>> That convention is opposite from what is used in sbitmap, where _cg
>> indicates that it returns the bool.  I think returning the value
>> will be the less common case.
>
>
> Sorry, I mixed the two up.  I meant the version that makes sense.

What's the issue with always returning the changed status?  bitmap operations
(even more so sbitmap operations) are memory-bound, accumulating one more
register isn't speed critial.

Richard.

>
> Diego.
>


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