Hi,
On Fri, Nov 16, 2012 at 08:08:52AM -0500, Diego Novillo wrote:
> On Fri, Nov 16, 2012 at 4:38 AM, Martin Jambor wrote:
>
> > So you do not plan to replace/rename at least some of them? This
> > seems like unnecessary and confusing layering just to avoid the work
> > to do the right thing.
>
Hi.
As an exercise, I am trying to implement a simple gcc pass
that unrolls the loops that have transactions.
The pass first identifies all the loops that have transactions,
and latter it unrolls the loop once by copying the loop body.
The pass works when I run gcc with -O0,
but it crashes gcc w
On Mon, Nov 19, 2012 at 5:18 AM, Martin Jambor wrote:
> Hi,
>
> On Fri, Nov 16, 2012 at 08:08:52AM -0500, Diego Novillo wrote:
>> On Fri, Nov 16, 2012 at 4:38 AM, Martin Jambor wrote:
>>
>> > So you do not plan to replace/rename at least some of them? This
>> > seems like unnecessary and confusi
Hi,
On Mon, 19 Nov 2012, Martin Jambor wrote:
> Well, this is what I was actually afraid of. If things like generic
> or tree dump of a tree value is selected by new TDF_ flags, then you
> are in danger of just replacing current mess in function names by a
> mess of constants. I'd much rather h
Hi,
On Fri, 16 Nov 2012, Lawrence Crowl wrote:
> I think the field "htab_t original_pddrs" in struct scop in
> graphite-poly.h is unused.
Seems I overlooked it during my post-isl cleanups. Yes, remove it.
Ciao,
Michael.
On Mon, Nov 19, 2012 at 10:11 AM, Michael Matz wrote:
> So, yes, the larger layouting should be determined by name of the dump
> function. A flag argument might look nice from an interface design
> perspective, but it's harder to use in the debugger.
As long as all these different objects share
On Sun, Nov 18, 2012 at 06:37:29PM +, Jonathan Wakely wrote:
> On 18 November 2012 18:25, Basile Starynkevitch wrote:
> > On Sun, Nov 18, 2012 at 08:06:08AM -1000, NightStrike wrote:
> >> On Sun, Nov 18, 2012 at 8:03 AM, Basile Starynkevitch
> >> wrote:
> >> > I really think that GCC need some
On 19 November 2012 19:35, Basile Starynkevitch wrote:
> On Sun, Nov 18, 2012 at 06:37:29PM +, Jonathan Wakely wrote:
>> On 18 November 2012 18:25, Basile Starynkevitch wrote:
>> > On Sun, Nov 18, 2012 at 08:06:08AM -1000, NightStrike wrote:
>> >> On Sun, Nov 18, 2012 at 8:03 AM, Basile Starynk
On 11/17/12, Hans-Peter Nilsson wrote:
> On Thu, 15 Nov 2012, Diego Novillo wrote:
> > === Approach: Move GTY to cc1plus.
> >
> > Instead of a separate weak parser, we would make cc1plus
> > understand GTY attributes. The compiler would emit IL in the
> > object files instead of generating source
On 11/16/12, Diego Novillo wrote:
> On Nov 16, 2012 Basile Starynkevitch wrote:
> > I actually disagree with the "Get rid of GC" idea, but I am not
> > sure that we all understand the same thing about it (and I have
> > the feeling of the opposite). I would probably agree with "Get
> > rid of Gen
I believe the following components in sese.[hc] are completely unused.
phis -- functions declared extern in sese.h but never defined
extern void insert_loop_close_phis (htab_t, loop_p);
extern void insert_guard_phis (basic_block, edge, edge, htab_t, htab_t);
ivtype_map -- the hash table infr
On Mon, 19 Nov 2012, Lawrence Crowl wrote:
> On 11/17/12, Hans-Peter Nilsson wrote:
> > On Thu, 15 Nov 2012, Diego Novillo wrote:
> > > === Approach: Move GTY to cc1plus.
> > >
> > > Instead of a separate weak parser, we would make cc1plus
> > > understand GTY attributes. The compiler would emit
On 11/12/12, Diego Novillo wrote:
> On Mon, Nov 12, 2012 at 2:31 PM, Lawrence Crowl wrote:
>> On 11/12/12, Lawrence Crowl wrote:
>>> It appears that
>>>
>>> static bitmap clear_alias_sets = NULL;
>>>
>>> is never set, and as a consequence
>>>
>>> clear_alias_set_lookup (alias_set_type alias_
On 11/19/2012 08:24 PM, Lawrence Crowl wrote:
On 11/16/12, Diego Novillo wrote:
On Nov 16, 2012 Basile Starynkevitch wrote:
I actually disagree with the "Get rid of GC" idea, but I am not
sure that we all understand the same thing about it (and I have
the feeling of the opposite). I would pro
Basile Starynkevitch writes:
> PS. LLVM has also a decisive documentation advantage w.r.t. GCC
What...? The last time I tried to do something with LLVM, the
internals docs were awful (full of kinda stuff,
usually just in the area I was confused about)... and gcc
historically has had great inte
On Tuesday 20 November 2012 10:30 AM, Miles Bader wrote:
Basile Starynkevitch writes:
PS. LLVM has also a decisive documentation advantage w.r.t. GCC
What...? The last time I tried to do something with LLVM, the
internals docs were awful (full of kinda stuff,
usually just in the area I wa
16 matches
Mail list logo
