On May 23, 2013, at 9:17 AM, David Edelsohn wrote:
> I want to have a version of the patch committed. The only question now
> is how much of the patch can be committed without exposing potential
> incompatibilities between different object files.
The hard part is to know when for certain, the dat
On Thu, May 23, 2013 at 11:18 AM, Bill Schmidt
wrote:
> On Thu, 2013-05-23 at 08:54 -0600, Sandra Loosemore wrote:
>> On 05/23/2013 06:29 AM, Bill Schmidt wrote:
>> >
>> > Sandra and David,
>> >
>> > The array-alignment patch is performance-neutral with respect to
>> > CPU2006. All variations wer
On Thu, 2013-05-23 at 08:54 -0600, Sandra Loosemore wrote:
> On 05/23/2013 06:29 AM, Bill Schmidt wrote:
> >
> > Sandra and David,
> >
> > The array-alignment patch is performance-neutral with respect to
> > CPU2006. All variations were in the noise range.
>
> Well, that settles it; I don't see a
On 05/23/2013 06:29 AM, Bill Schmidt wrote:
Sandra and David,
The array-alignment patch is performance-neutral with respect to
CPU2006. All variations were in the noise range.
Well, that settles it; I don't see any reason to pursue the patch any
further if it's not a performance win after a
On Tue, 2013-05-21 at 21:57 -0400, David Edelsohn wrote:
> On Tue, May 21, 2013 at 7:13 PM, Sandra Loosemore
> wrote:
> > On 05/21/2013 04:04 PM, David Edelsohn wrote:
> >>
> >>
> >> There are three issues here:
> >>
> >> 1) Someone in the LTC toolchain team needs to benchmark this patch on
> >> P
On Wed, May 22, 2013 at 07:57:34AM -0600, Sandra Loosemore wrote:
> On 05/22/2013 02:01 AM, Richard Biener wrote:
> >Maybe the idea was to increase the alignment of the struct (without
> >affecting it's layout) when that increases the alignment of a contained
> >array member. Like for
> >
> >struc
On Wed, May 22, 2013 at 3:57 PM, Sandra Loosemore
wrote:
> On 05/22/2013 02:01 AM, Richard Biener wrote:
>>
>> On Wed, May 22, 2013 at 3:57 AM, David Edelsohn wrote:
>>>
>>>
>>> Increasing the alignment of arrays within structs and unions would be
>>> nice, but that probably will change the ABI.
On 05/22/2013 02:01 AM, Richard Biener wrote:
On Wed, May 22, 2013 at 3:57 AM, David Edelsohn wrote:
Increasing the alignment of arrays within structs and unions would be
nice, but that probably will change the ABI. I think that they best we
may be able to do is increase the alignment if the a
On Wed, May 22, 2013 at 3:57 AM, David Edelsohn wrote:
> On Tue, May 21, 2013 at 7:13 PM, Sandra Loosemore
> wrote:
>> On 05/21/2013 04:04 PM, David Edelsohn wrote:
>>>
>>>
>>> There are three issues here:
>>>
>>> 1) Someone in the LTC toolchain team needs to benchmark this patch on
>>> POWER7.
>
On Tue, May 21, 2013 at 10:16 PM, Bill Schmidt
wrote:
> I can take a look at this tomorrow. I think I should probably commit
> the other pending patch I have first. There was some discussion on my
> patch whether it was the right approach, but given the behavior of
> existing allocators I think
On Tue, 2013-05-21 at 21:57 -0400, David Edelsohn wrote:
> On Tue, May 21, 2013 at 7:13 PM, Sandra Loosemore
> wrote:
> > On 05/21/2013 04:04 PM, David Edelsohn wrote:
> >>
> >>
> >> There are three issues here:
> >>
> >> 1) Someone in the LTC toolchain team needs to benchmark this patch on
> >> P
On Tue, May 21, 2013 at 7:13 PM, Sandra Loosemore
wrote:
> On 05/21/2013 04:04 PM, David Edelsohn wrote:
>>
>>
>> There are three issues here:
>>
>> 1) Someone in the LTC toolchain team needs to benchmark this patch on
>> POWER7.
>
>
> That would be great if somebody else could help with that.
>
>
On 05/21/2013 04:04 PM, David Edelsohn wrote:
There are three issues here:
1) Someone in the LTC toolchain team needs to benchmark this patch on POWER7.
That would be great if somebody else could help with that.
2) We need to clarify how the patch affects the ABI because it cannot
break the
On Tue, May 21, 2013 at 5:49 PM, Sandra Loosemore
wrote:
> On 05/20/2013 03:20 PM, David Edelsohn wrote:
>>
>> This seems like a reasonable change and *should* improve performance,
>> but what is the actual effect on performance, especially recent POWER
>> processors? We have had some recent case
On 05/20/2013 03:20 PM, David Edelsohn wrote:
This seems like a reasonable change and *should* improve performance,
but what is the actual effect on performance, especially recent POWER
processors? We have had some recent cases where increased alignment
hurt performance because of secondary effe
On Mon, May 20, 2013 at 10:51:16PM -0600, Sandra Loosemore wrote:
> On 05/20/2013 04:14 PM, Jakub Jelinek wrote:
> >
> >Isn't this ABI incompatible change? See http://gcc.gnu.org/PR56564
> >for more info (yeah, different target, but looks exactly the same issue).
> >If what this new DATA_ALIGNMENT
On 05/20/2013 04:14 PM, Jakub Jelinek wrote:
Isn't this ABI incompatible change? See http://gcc.gnu.org/PR56564
for more info (yeah, different target, but looks exactly the same issue).
If what this new DATA_ALIGNMENT value is optimization rather than an ABI
requirement, then you'll hit the sam
On Mon, May 20, 2013 at 10:40:40AM -0600, Sandra Loosemore wrote:
> This patch is a revised version of one previously posted by Pat
> Wellander a couple of years ago, to align arrays of size >= 16 bytes
> on a 16-byte boundary to make better use of Altivec instructions.
>
> http://gcc.gnu.org/ml/g
This seems like a reasonable change and *should* improve performance,
but what is the actual effect on performance, especially recent POWER
processors? We have had some recent cases where increased alignment
hurt performance because of secondary effects on spilling.
Thanks, David
On May 20, 2013, at 9:40 AM, Sandra Loosemore wrote:
> The original patch only increased the alignment of local arrays, which works
> because the stack is already aligned at 16 bytes for Altivec. The comments
> on the original patch submission were that this should apply to all arrays
> and th
This patch is a revised version of one previously posted by Pat
Wellander a couple of years ago, to align arrays of size >= 16 bytes on
a 16-byte boundary to make better use of Altivec instructions.
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01345.html
The original patch only increased the a
21 matches
Mail list logo
