On 10/30/12, Diego Novillo wrote:
> On Oct 30, 2012 Bin.Cheng wrote:
> > Just one question: Should we change the name of functions
> > "sbitmap_intersection_of_succs/sbitmap_intersection_of_preds/
> > sbitmap_union_of_succs/sbitmap_union_of_preds" too? It might
> > be a little confusing that sbit
On Tue, Oct 30, 2012 at 12:53 PM, Diego Novillo wrote:
> On Mon, Oct 29, 2012 at 4:25 PM, Steven Bosscher
> wrote:
>> On Mon, Oct 29, 2012 at 7:54 PM, Diego Novillo wrote:
>>
>>> Sure. But the point is not to add more. We should mechanically strip
>>> all the #if 0 code from the tree, btw. No
On Mon, Oct 29, 2012 at 4:25 PM, Steven Bosscher wrote:
> On Mon, Oct 29, 2012 at 7:54 PM, Diego Novillo wrote:
>
>> Sure. But the point is not to add more. We should mechanically strip
>> all the #if 0 code from the tree, btw. No point keeping all that
>> garbage around.
>
> Please no. A lot (
On Tue, Oct 30, 2012 at 2:17 AM, Bin.Cheng wrote:
> On Tue, Oct 30, 2012 at 8:23 AM, Lawrence Crowl wrote:
>> On 10/29/12, Diego Novillo wrote:
>>> On Oct 29, 2012 Diego Novillo wrote:
>>> > Just to make sure. Testing on ppc should be fast, for example.
>>>
>>> And useless. Your patch does no
On Tue, Oct 30, 2012 at 8:23 AM, Lawrence Crowl wrote:
> On 10/29/12, Diego Novillo wrote:
>> On Oct 29, 2012 Diego Novillo wrote:
>> > Just to make sure. Testing on ppc should be fast, for example.
>>
>> And useless. Your patch does not touch ppc.
>
> I've fixed the #if 0 and the remaining su
On Mon, Oct 29, 2012 at 2:54 PM, Diego Novillo wrote:
> Just to make sure. Testing on ppc should be fast, for example.
And useless. Your patch does not touch ppc.
Diego.
On Mon, Oct 29, 2012 at 7:54 PM, Diego Novillo wrote:
> Sure. But the point is not to add more. We should mechanically strip
> all the #if 0 code from the tree, btw. No point keeping all that
> garbage around.
Please no. A lot (if not most) if the #if 0 code serves as good
documentation for wh
On 10/29/12, Diego Novillo wrote:
> On Oct 29, 2012 Lawrence Crowl wrote:
> > The sbitmap popcount function is only used in ebitmap, which is
> > itself not used. If we do anything, removing them might be the
> > thing to do.
>
> Yes, please.
Separate patch, please.
> > The bitmap.h iterators
On Mon, Oct 29, 2012 at 2:46 PM, Lawrence Crowl wrote:
> Okay, but I point out that there is an awful lot of #if 0 code
> out there. I would rather have done such removal in a followup
> patch.
Sure. But the point is not to add more. We should mechanically strip
all the #if 0 code from the tr
On 10/29/12, Richard Biener wrote:
> On Oct 29, 2012 Diego Novillo wrote:
> > On Oct 25, 2012 Lawrence Crowl wrote:
> > > The sbitmap non-bool returning bitwise operations have been
> > > merged with the bool versions. Sometimes this merge involved
> > > modifying the non-bool version to comput
On Mon, Oct 29, 2012 at 2:06 PM, Diego Novillo wrote:
> On Thu, Oct 25, 2012 at 6:39 PM, Lawrence Crowl wrote:
>
>> The sbitmap non-bool returning bitwise operations have been merged with
>> the bool versions. Sometimes this merge involved modifying the non-bool
>> version to compute the bool va
On Thu, Oct 25, 2012 at 6:39 PM, Lawrence Crowl wrote:
> The sbitmap non-bool returning bitwise operations have been merged with
> the bool versions. Sometimes this merge involved modifying the non-bool
> version to compute the bool value, and sometimes modifying bool version to
> add additional
On 10/25/12, Lawrence Crowl wrote:
> This patch implements the unification of the *bitmap interfaces as
> discussed.
> Essentially, we rename ebitmap and sbitmap functions to use the same names
> as the bitmap functions. This rename works because we can now overload
> on the bitmap type. Some ma
13 matches
Mail list logo
