On 2012-10-15 13:21 , Lawrence Crowl wrote:
Given this, and that the other bitmap interfaces mostly return a
changed flag, we should opt for the simpler API, always returning
it. That includes the few remaining bitmap.h functions that
aren't already doing so.
Does anyone have objections to th
On 10/15/12, Michael Matz wrote:
> On Sat, 13 Oct 2012, Lawrence Crowl wrote:
> > > > I have no problem in always returning a status change,
> > > > if you are OK with that.
> > >
> > > I am ok with that.
> >
> > There is some rationale for being concerned about performance,
> > as the checking ro
Hi,
On Sat, 13 Oct 2012, Lawrence Crowl wrote:
> > > I have no problem in always returning a status change, if you are OK
> > > with that.
> >
> > I am ok with that.
>
> There is some rationale for being concerned about performance, as the
> checking routines need to read memory locations that
On 10/12/12, Richard Biener wrote:
> On Oct 12, 2012 Diego Novillo wrote:
> > On 2012-10-12 04:26 , Richard Biener wrote:
> > > What's the issue with always returning the changed status?
> > > bitmap operations (even more so sbitmap operations) are
> > > memory-bound, accumulating one more regist
On Fri, Oct 12, 2012 at 3:37 PM, Diego Novillo wrote:
> On 2012-10-12 04:26 , Richard Biener wrote:
>
>> 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.
>
On 2012-10-12 04:26 , Richard Biener wrote:
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.
Not a big issue, but it was going to be a behaviour change, which we
On Thu, Oct 11, 2012 at 11:57 PM, Diego Novillo wrote:
> On 2012-10-11 16:25 , Lawrence Crowl wrote:
>>
>> On 10/11/12, Diego Novillo 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
On 2012-10-11 16:25 , Lawrence Crowl wrote:
On 10/11/12, Diego Novillo 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. Howeve
On 10/11/12, Diego Novillo 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 w
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 th
On 10/11/12, Richard Biener wrote:
> On Oct 11, 2012, Lawrence Crowl wrote:
>> As part of our effort to make programming in GCC easier, we would like
>> to improve the interface to bitmaps.
>>
>> There are three bitmap types, each with disparate operations and
>> function names. This disparity c
On Thu, Oct 11, 2012 at 9:01 AM, Richard Biener
wrote:
> I'd rather not mix this with any kind of further C++-ification (that is
> introduction of member functions or operator overloads).
Agreed. At first I was surprised that Lawrence had not done the
obvious operator overloads, but the introdu
On Thu, Oct 11, 2012 at 3:08 AM, Lawrence Crowl wrote:
> As part of our effort to make programming in GCC easier, we would like
> to improve the interface to bitmaps.
>
> There are three bitmap types, each with disparate operations and
> function names. This disparity causes problems
> * when cha
As part of our effort to make programming in GCC easier, we would like
to improve the interface to bitmaps.
There are three bitmap types, each with disparate operations and
function names. This disparity causes problems
* when changing a variable from one type to another,
* when moving one's atte
14 matches
Mail list logo
