ping * 3 https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01703.html
Thanks,
Prathamesh
On 5 July 2016 at 10:53, Prathamesh Kulkarni
wrote:
> ping * 2 ping https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01703.html
>
> Thanks,
> Prathamesh
>
> On 28 June 2016 at 14:49, Prathamesh Kulkarni
> wrote:
>
ping * 2 ping https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01703.html
Thanks,
Prathamesh
On 28 June 2016 at 14:49, Prathamesh Kulkarni
wrote:
> ping https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01703.html
>
> Thanks,
> Prathamesh
>
> On 23 June 2016 at 22:51, Prathamesh Kulkarni
> wrote:
>> O
ping https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01703.html
Thanks,
Prathamesh
On 23 June 2016 at 22:51, Prathamesh Kulkarni
wrote:
> On 17 June 2016 at 19:52, Prathamesh Kulkarni
> wrote:
>> On 14 June 2016 at 18:31, Prathamesh Kulkarni
>> wrote:
>>> On 13 June 2016 at 16:13, Jan Hubicka w
On 17 June 2016 at 19:52, Prathamesh Kulkarni
wrote:
> On 14 June 2016 at 18:31, Prathamesh Kulkarni
> wrote:
>> On 13 June 2016 at 16:13, Jan Hubicka wrote:
diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index ecafe63..41ac408 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -
On 14 June 2016 at 18:31, Prathamesh Kulkarni
wrote:
> On 13 June 2016 at 16:13, Jan Hubicka wrote:
>>> diff --git a/gcc/cgraph.h b/gcc/cgraph.h
>>> index ecafe63..41ac408 100644
>>> --- a/gcc/cgraph.h
>>> +++ b/gcc/cgraph.h
>>> @@ -1874,6 +1874,9 @@ public:
>>> if we did not do any inter-p
On 13 June 2016 at 16:13, Jan Hubicka wrote:
>> diff --git a/gcc/cgraph.h b/gcc/cgraph.h
>> index ecafe63..41ac408 100644
>> --- a/gcc/cgraph.h
>> +++ b/gcc/cgraph.h
>> @@ -1874,6 +1874,9 @@ public:
>> if we did not do any inter-procedural code movement. */
>>unsigned used_by_single_fun
> diff --git a/gcc/cgraph.h b/gcc/cgraph.h
> index ecafe63..41ac408 100644
> --- a/gcc/cgraph.h
> +++ b/gcc/cgraph.h
> @@ -1874,6 +1874,9 @@ public:
> if we did not do any inter-procedural code movement. */
>unsigned used_by_single_function : 1;
>
> + /* Set if -fsection-anchors is se
On 10 June 2016 at 16:47, Richard Biener wrote:
> On Fri, 10 Jun 2016, Prathamesh Kulkarni wrote:
>
>> On 10 June 2016 at 01:53, Jan Hubicka wrote:
>> >> On 8 June 2016 at 20:38, Jan Hubicka wrote:
>> >> >> I think it would be nice to work towards transitioning
>> >> >> flag_section_anchors to a
On Fri, 10 Jun 2016, Prathamesh Kulkarni wrote:
> On 10 June 2016 at 01:53, Jan Hubicka wrote:
> >> On 8 June 2016 at 20:38, Jan Hubicka wrote:
> >> >> I think it would be nice to work towards transitioning
> >> >> flag_section_anchors to a flag on varpool nodes, thereby removing
> >> >> the Opt
On 10 June 2016 at 01:53, Jan Hubicka wrote:
>> On 8 June 2016 at 20:38, Jan Hubicka wrote:
>> >> I think it would be nice to work towards transitioning
>> >> flag_section_anchors to a flag on varpool nodes, thereby removing
>> >> the Optimization flag from common.opt:fsection-anchors
>> >>
>> >>
On 8 June 2016 at 20:38, Jan Hubicka wrote:
>> I think it would be nice to work towards transitioning
>> flag_section_anchors to a flag on varpool nodes, thereby removing
>> the Optimization flag from common.opt:fsection-anchors
>>
>> That would simplify the walk over varpool candidates.
>
> Makes
> On 8 June 2016 at 20:38, Jan Hubicka wrote:
> >> I think it would be nice to work towards transitioning
> >> flag_section_anchors to a flag on varpool nodes, thereby removing
> >> the Optimization flag from common.opt:fsection-anchors
> >>
> >> That would simplify the walk over varpool candidate
> I think it would be nice to work towards transitioning
> flag_section_anchors to a flag on varpool nodes, thereby removing
> the Optimization flag from common.opt:fsection-anchors
>
> That would simplify the walk over varpool candidates.
Makes sense to me, too. There are more candidates for su
On Tue, 7 Jun 2016, Prathamesh Kulkarni wrote:
> On 3 June 2016 at 13:35, Jan Hubicka wrote:
> >> > fsection-anchors
> >> > Common Report Var(flag_section_anchors)
> >> > Access data in the same section from shared anchor points.
> >>
> >> Funny. I see the following on trunk:
> >>
> >> fsection-
On 3 June 2016 at 13:35, Jan Hubicka wrote:
>> > fsection-anchors
>> > Common Report Var(flag_section_anchors)
>> > Access data in the same section from shared anchor points.
>>
>> Funny. I see the following on trunk:
>>
>> fsection-anchors
>> Common Report Var(flag_section_anchors) Optimization
> > fsection-anchors
> >
> > Common Report Var(flag_section_anchors)
> >
> > Access data in the same section from shared anchor points.
> >
>
> Funny. I see the follow
On Thu, 2 Jun 2016, Jan Hubicka wrote:
> > On Thu, 2 Jun 2016, David Edelsohn wrote:
> >
> > > > Richard Biener wrote:
> > >
> > > >> "This would mean the pass should get its own non-Optimization flag
> > > >> initialized by targets where section anchors are usually used"
> > > >> IIUC shoul
> On Thu, 2 Jun 2016, David Edelsohn wrote:
>
> > > Richard Biener wrote:
> >
> > >> "This would mean the pass should get its own non-Optimization flag
> > >> initialized by targets where section anchors are usually used"
> > >> IIUC should we add a new option -fno-increase_alignment and gate
On Thu, 2 Jun 2016, David Edelsohn wrote:
> > Richard Biener wrote:
>
> >> "This would mean the pass should get its own non-Optimization flag
> >> initialized by targets where section anchors are usually used"
> >> IIUC should we add a new option -fno-increase_alignment and gate the
> >> pass
> Richard Biener wrote:
>> "This would mean the pass should get its own non-Optimization flag
>> initialized by targets where section anchors are usually used"
>> IIUC should we add a new option -fno-increase_alignment and gate the
>> pass on it ? Um sorry I didn't understand why targets
>> wi
On 2 June 2016 at 14:44, Prathamesh Kulkarni
wrote:
> On 2 June 2016 at 13:23, Richard Biener wrote:
>> On Thu, 2 Jun 2016, Prathamesh Kulkarni wrote:
>>
>>> On 1 June 2016 at 18:37, Richard Biener wrote:
>>> > On Wed, 1 Jun 2016, Prathamesh Kulkarni wrote:
>>> >
>>> >> Hi Richard,
>>> >> This p
On 2 June 2016 at 13:23, Richard Biener wrote:
> On Thu, 2 Jun 2016, Prathamesh Kulkarni wrote:
>
>> On 1 June 2016 at 18:37, Richard Biener wrote:
>> > On Wed, 1 Jun 2016, Prathamesh Kulkarni wrote:
>> >
>> >> Hi Richard,
>> >> This patch tries to move increase_alignment pass from small to regul
On Thu, 2 Jun 2016, Prathamesh Kulkarni wrote:
> On 1 June 2016 at 18:37, Richard Biener wrote:
> > On Wed, 1 Jun 2016, Prathamesh Kulkarni wrote:
> >
> >> Hi Richard,
> >> This patch tries to move increase_alignment pass from small to regular ipa
> >> pass.
> >> Does the patch look correct ?
>
On 1 June 2016 at 18:37, Richard Biener wrote:
> On Wed, 1 Jun 2016, Prathamesh Kulkarni wrote:
>
>> Hi Richard,
>> This patch tries to move increase_alignment pass from small to regular ipa
>> pass.
>> Does the patch look correct ?
>> Since we are only increasing alignment of varpool nodes, I am
On Wed, 1 Jun 2016, Prathamesh Kulkarni wrote:
> Hi Richard,
> This patch tries to move increase_alignment pass from small to regular ipa
> pass.
> Does the patch look correct ?
> Since we are only increasing alignment of varpool nodes, I am not sure
> if any ipa
> read/write hooks were necessary
Hi Richard,
This patch tries to move increase_alignment pass from small to regular ipa pass.
Does the patch look correct ?
Since we are only increasing alignment of varpool nodes, I am not sure
if any ipa
read/write hooks were necessary and passed NULL for them.
Cross-tested on arm*-*-*, aarch64*-*
26 matches
Mail list logo
