From patchwork Tue Apr 26 07:16:57 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 1622225 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=DX/9xS7+; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4KnYnZ6LXqz9s0B for ; Tue, 26 Apr 2022 17:45:05 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3FE453858C74 for ; Tue, 26 Apr 2022 07:45:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3FE453858C74 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1650959102; bh=aJf5KFiUNaeseGfbdExtTwR0mNScZch2/K5UmwmXG9Y=; h=Resent-From:Resent-Date:Resent-To:Date:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=DX/9xS7+OfGs8jfVZqs4xrKpIx9p/JBciw6XVTIwRODw6dM9Zc/1xnmu7iMGRVpcq O8KQhBpTeUfNzhOBZcHeBfkkubQ6C8ZYxK6EVBBLFDHAkx7fOgyuVJn58Dzbj7wL/o qnkBV7CjC1OLEpGhqVr/zoRz+Dp8nKuYuyZZ7jR4= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 899B73858D1E for ; Tue, 26 Apr 2022 07:44:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 899B73858D1E Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-627-E29jV9nLNNy9G1OrTE0nLw-1; Tue, 26 Apr 2022 03:44:40 -0400 X-MC-Unique: E29jV9nLNNy9G1OrTE0nLw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C15DE86B8A4 for ; Tue, 26 Apr 2022 07:44:39 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 81808112131B for ; Tue, 26 Apr 2022 07:44:39 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 23Q7iBr03658025 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for ; Tue, 26 Apr 2022 09:44:22 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 23Q7i13r3658020 for gcc-patches@gcc.gnu.org; Tue, 26 Apr 2022 09:44:01 +0200 Resent-From: Jakub Jelinek Resent-Date: Tue, 26 Apr 2022 09:44:01 +0200 Resent-Message-ID: Resent-To: gcc-patches@gcc.gnu.org Date: Tue, 26 Apr 2022 09:16:57 +0200 To: gcc-patches@gcc.gnu.org Subject: [committed] libgomp: Fix up two non-GOMP_USE_ALIGNED_WORK_SHARES related issues [PR105358] Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Jakub Jelinek via Gcc-patches From: Jakub Jelinek Reply-To: Jakub Jelinek Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" Hi! Last fall I've changed struct gomp_work_share, so that it doesn't have __attribute__((aligned (64))) lock member in the middle unless the target has non-emulated aligned allocator, otherwise it just makes sure the first and second halves are 64 bytes appart for cache line reasons, but doesn't make the struct 64-byte aligned itself and so we can use normal allocators for it. When the struct isn't 64-byte aligned, the amount of tail padding significantly decreases, to 0 or 4 bytes or so. The library uses that tail padding when the ordered_teams_ids array (array of uints) and/or the memory for lastprivate conditional temporaries (the latter wants to guarantee long long alignment). The problem with it on ia32 darwin9 is that while the struct contains long long members, long long is just 4 byte aligned while __alignof__(long long) is 8. That causes problems in gomp_init_work_share, where we currently rely on if offsetof (struct gomp_work_share, inline_ordered_team_ids) is long long aligned, then that tail array will be aligned at runtime and so no extra memory for dynamic realignment will be needed (that is false when the whole struct doesn't have long long alignment). And also in the remaining hunks causes another problem, where we compute INLINE_ORDERED_TEAM_IDS_OFF as the above offsetof aligned up to long long boundary and subtract sizeof (struct gomp_work_share) and INLINE_ORDERED_TEAM_IDS_OFF. When unlucky, the former isn't multiple of 8 and the latter is 4 bigger than that and as the subtraction is done in size_t, we end up with (size_t) -4, so the comparison doesn't really work. The fixes add additional conditions to make it work properly, but all of them should be evaluated at compile time when optimizing and so shouldn't slow anything. Bootstrapped/regtested on x86_64-linux and i686-linux and in the PR Iain said he has tested it on affected targets, committed to trunk. 2022-04-26 Jakub Jelinek PR libgomp/105358 * work.c (gomp_init_work_share): Don't mask of adjustment for dynamic long long realignment if struct gomp_work_share has smaller alignof than long long. * loop.c (GOMP_loop_start): Don't use inline_ordered_team_ids if struct gomp_work_share has smaller alignof than long long or if sizeof (struct gomp_work_share) is smaller than INLINE_ORDERED_TEAM_IDS_OFF. * loop_ull.c (GOMP_loop_ull_start): Likewise. * sections.c (GOMP_sections2_start): Likewise. Jakub --- libgomp/work.c.jj 2022-01-11 23:11:23.944268316 +0100 +++ libgomp/work.c 2022-04-25 13:42:24.885500128 +0200 @@ -113,7 +113,9 @@ gomp_init_work_share (struct gomp_work_s size_t o = nthreads * sizeof (*ws->ordered_team_ids); o += __alignof__ (long long) - 1; if ((offsetof (struct gomp_work_share, inline_ordered_team_ids) - & (__alignof__ (long long) - 1)) == 0) + & (__alignof__ (long long) - 1)) == 0 + && __alignof__ (struct gomp_work_share) + >= __alignof__ (long long)) o &= ~(__alignof__ (long long) - 1); ordered += o - 1; } --- libgomp/loop.c.jj 2022-01-11 23:11:23.890269075 +0100 +++ libgomp/loop.c 2022-04-25 13:39:24.266009817 +0200 @@ -270,8 +270,11 @@ GOMP_loop_start (long start, long end, l #define INLINE_ORDERED_TEAM_IDS_OFF \ ((offsetof (struct gomp_work_share, inline_ordered_team_ids) \ + __alignof__ (long long) - 1) & ~(__alignof__ (long long) - 1)) - if (size > (sizeof (struct gomp_work_share) - - INLINE_ORDERED_TEAM_IDS_OFF)) + if (sizeof (struct gomp_work_share) + <= INLINE_ORDERED_TEAM_IDS_OFF + || __alignof__ (struct gomp_work_share) < __alignof__ (long long) + || size > (sizeof (struct gomp_work_share) + - INLINE_ORDERED_TEAM_IDS_OFF)) *mem = (void *) (thr->ts.work_share->ordered_team_ids = gomp_malloc_cleared (size)); --- libgomp/loop_ull.c.jj 2022-01-11 23:11:23.890269075 +0100 +++ libgomp/loop_ull.c 2022-04-25 13:40:49.221829365 +0200 @@ -269,8 +269,11 @@ GOMP_loop_ull_start (bool up, gomp_ull s #define INLINE_ORDERED_TEAM_IDS_OFF \ ((offsetof (struct gomp_work_share, inline_ordered_team_ids) \ + __alignof__ (long long) - 1) & ~(__alignof__ (long long) - 1)) - if (size > (sizeof (struct gomp_work_share) - - INLINE_ORDERED_TEAM_IDS_OFF)) + if (sizeof (struct gomp_work_share) + <= INLINE_ORDERED_TEAM_IDS_OFF + || __alignof__ (struct gomp_work_share) < __alignof__ (long long) + || size > (sizeof (struct gomp_work_share) + - INLINE_ORDERED_TEAM_IDS_OFF)) *mem = (void *) (thr->ts.work_share->ordered_team_ids = gomp_malloc_cleared (size)); --- libgomp/sections.c.jj 2022-01-11 23:11:23.913268752 +0100 +++ libgomp/sections.c 2022-04-25 13:41:12.423506981 +0200 @@ -121,8 +121,11 @@ GOMP_sections2_start (unsigned count, ui #define INLINE_ORDERED_TEAM_IDS_OFF \ ((offsetof (struct gomp_work_share, inline_ordered_team_ids) \ + __alignof__ (long long) - 1) & ~(__alignof__ (long long) - 1)) - if (size > (sizeof (struct gomp_work_share) - - INLINE_ORDERED_TEAM_IDS_OFF)) + if (sizeof (struct gomp_work_share) + <= INLINE_ORDERED_TEAM_IDS_OFF + || __alignof__ (struct gomp_work_share) < __alignof__ (long long) + || size > (sizeof (struct gomp_work_share) + - INLINE_ORDERED_TEAM_IDS_OFF)) *mem = (void *) (thr->ts.work_share->ordered_team_ids = gomp_malloc_cleared (size));