This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] S/390: Hardware transactional memory support
- From: David Edelsohn <dje dot gcc at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>, Peter Bergner <bergner at vnet dot ibm dot com>
- Cc: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 16 Jul 2013 08:08:53 -0400
- Subject: Re: [PATCH] S/390: Hardware transactional memory support
- References: <20130621102314 dot GA753 at bart> <20130715193231 dot GR2475 at laptop dot redhat dot com> <1373919992 dot 4538 dot 177 dot camel at otta> <CAGWvny=6AdC-SHjj-h+zcdJFsOVXY8ORFchvbtuiViMRJXZA7Q at mail dot gmail dot com> <1373946004 dot 4538 dot 183 dot camel at otta> <20130716052431 dot GA23578 at laptop dot redhat dot com>
On Tue, Jul 16, 2013 at 1:24 AM, Jakub Jelinek <firstname.lastname@example.org> wrote:
> On Mon, Jul 15, 2013 at 10:40:04PM -0500, Peter Bergner wrote:
>> On Mon, 2013-07-15 at 23:03 -0400, David Edelsohn wrote:
>> > On Mon, Jul 15, 2013 at 4:26 PM, Peter Bergner <email@example.com> wrote:
>> > > David, do you prefer reverting the above hunk from the Power HTM
>> > > patch or should I add the associated -mno-* options to the building
>> > > of libitm?
>> > How is libitm built for Intel? The principle of least surprises
>> > suggests following that precedent.
>> They use -mrtm (like we use -mhtm) to build libitm, but it looks like
>> their -mrtm does not enable any other isa flags like we currently are
>> doing with -mhtm. Meaning their -mrtm option is independent of any
>> -mcpu values while ours is not. If we revert the patch I mentioned,
>> then I think we will match what Intel is doing.
>> Hopefully Jakub will correct me if I am wrong.
> Yes, that is my understanding of it too. On Intel we have:
> #define OPTION_MASK_ISA_RTM_SET OPTION_MASK_ISA_RTM
> #define OPTION_MASK_ISA_RTM_UNSET OPTION_MASK_ISA_RTM
> which means that -mrtm doesn't set any other options except for itself
> and -mno-rtm doesn't reset other options. libitm is built with -mrtm,
> assuming that the only thing the -mrtm switch affects are the HTM builtins
> and that those will only be found explicitly in code guarded with the
> htm_available () runtime check.
> Right now, -mhtm on PowerPC basically implies -march=power8 if I understand
> the code well, and libitm is built with it, which means essentially that
> when gcc is configured for a pre-power8 CPU, libitm will work just fine on
> power8 (including HTM support), but when running on power7 and earlier
> it might very well SIGILL, because the implicit -march=power8 could affect
> even code not guarded by htm_available ().
> And on s/390, right now we enable HTM support in libitm when configured for
> -march=zEC12 by default (which isn't ideal).
Then I agree that the hunk should be reverted so that HTM does not imply POWER8.