This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] aarch64 suuport for libitm
- From: pinskia at gmail dot com
- To: Richard Henderson <rth at redhat dot com>
- Cc: Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Marcus Shawcroft <marcus dot shawcroft at arm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 2 Apr 2014 08:55:44 -0700
- Subject: Re: [PATCH] aarch64 suuport for libitm
- Authentication-results: sourceware.org; auth=none
- References: <533B3CA6 dot 90305 at redhat dot com> <CA+=Sn1mn663u6nMxbJK6Zbs-9-2VjSdWy_-iwkZ4QF-XTr4EYQ at mail dot gmail dot com> <533C20B6 dot 1070500 at redhat dot com>
> On Apr 2, 2014, at 7:37 AM, Richard Henderson <firstname.lastname@example.org> wrote:
>> On 04/01/2014 03:41 PM, Andrew Pinski wrote:
>>> On Tue, Apr 1, 2014 at 3:24 PM, Richard Henderson <email@example.com> wrote:
>>> Comments? If approved, should this go in for 4.9, or wait for stage1?
>>> Certainly it's self-contained...
>> On Cavium's thunder processor the cache line size is going to be
>> bigger than 64 bytes, what is your solution to improve performance on
>> target's like Thunder?
> We can expand the number reasonably. The only thing it controls is layout of
> some of the internal data structures to attempt to put different locks on
> different lines.
> Is 128 big enough for Thunder? Honestly, I may well not even have it right for
> the processor we have in house. I didn't bother trying to track down docs to
> find out.
Yes 128 should be enough.
>> Also I think the default page size for most Linux distros is going to
>> be 64k on aarch64 including Redhat Linux so it makes sense not to
>> define FIXED_PAGE_SIZE.
> Heh. It turns out these page size defines aren't used any more at all. During
> one of the rewrites we must have delete the bits that used it. I'll get rid of
> all of them so as to be less confusing.
>> I will implement the ILP32 version of this patch once it goes in,
>> there needs a few changes in gtm_jmpbuf due to long and pointers being
>> 32bit but the assembly storing 64bits always.
> I can minimize those changes now by using unsigned long long...