[Openmp-dev] AArch64 support

Tue Dec 23 05:55:54 PST 2014

As you say, it is holiday season and many people (including Johnny) are on vacation.

I am nervous about committing a change and then immediately going on holiday myself, (especially when the ball was in your court on these patches that are now so urgent for ~6 weeks).

Having a buildbot is great, especially if it is pushing results somewhere public, but surely your buildbot should only need a one line change to choose which repository to check out from, so you can do most of the work to get it running with it looking at your internal tree, and then switch to the LLVM tree easily once it’s all running.

More generally (and not needed for these patches, but so you can see where we’re going), I’d like to tidy up the way we’re handling the multiple architectures to make the code cleaner and porting easier.

At the moment we’re growing long #if chains like
#if KMP_OS_LINUX && (KMP_ARCH_X86 || KMP_ARCH_X86_64 || KMP_ARCH_ARM || KMP_ARCH_AARCH64)
which are hard to read and hard to get right.

I’d like to fix that in two ways

1.    Have #defines for the high level, generic architectures, e.g.

KMP_ARCH_X86_ANY, KMP_ARCH_ARM_ANY, KMP_ARCH_PPC_ANY, …

These would then be defined in terms of the possible architectures they represent, something like

#define KMP_ARCH_X86_ANY (KMP_ARCH_X86 || KMP_ARCH_X86_64)

#define KMP_ARCH_ARM_ANY (KMP_ARCH_ARM || KMP_ARCH_AARCH64)

#define KMP_ARCH_PPC_ANY (KMP_ARCH_PPC || KMP_ARCH_PPC64)     // or might be PPC32 || PPC?

For PPC we’d also have the endian options one level down within KMP_ARCH_PPC64, which would be

#define KMP_ARCH_PPC64 (KMP_ARCH_PPC64_LE || KMP_ARCH_PPC64_BE)

That would allow us to shorten the long chains like that above, which would then be
#if KMP_OS_LINUX && (KMP_ARCH_X86_ANY || KMP_ARCH_ARM_ANY)
which is somewhat better, but I’d also like to add the second change…

2.    Define some more functional/property style macros, so, for instance, that big if above is actually being used for the concept of “Does this system support futexes?”. I’d rather have a macro for that concept, which could then be defined in the architecture header, something like

#define KMP_HAVE_FUTEX (KMP_OS_LINUX && (KMP_ARCH_X86_ANY || KMP_ARCH_ARM_ANY))

(or, alternatively, which might be better, have a single #if section for each architecture that defines its capabilities as 1 or 0)

The code in kmp_csupport.c that’s worried about futexes would then just have

#if (KMP_HAVE_FUTEX)

This ought to make porting much simpler, since you wouldn’t need to look at every #if in the code that tests an architecture flag to see if your new architecture needs to be added, but just set the appropriate capability macros for the architecture you have and worry about any really machine specific code (which should get caught by a #error case).

p.s. I am out from this evening (3h30 and counting…) and will be back in the office on 23 February. (Sabbatical, yay! No snow in the Alps, boo!). Andrey Churbanov has commit rights, as does Hal. I trust them in my absence.

-- Jim

James Cownie <james.h.cownie at intel.com>
SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)
Tel: +44 117 9071438

From: C Bergström [mailto:cbergstrom at pathscale.com]
Sent: Monday, December 22, 2014 7:39 PM
To: Peyton, Jonathan L
Cc: openmp-dev at dcs-maillist2.engr.illinois.edu; Cownie, James H; Bliss, Brian E
Subject: Re: [Openmp-dev] AArch64 support

ping - it would be great if my patch could get reviewed/pushed. I realize it's the holidays, but I'm trying to use this time to get a buildbot setup and using upstream.

Thanks
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20141223/4d6a220e/attachment.html>