From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 64AF0405A1 for ; Sun, 18 Feb 2024 16:29:43 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id BE70068D36C; Sun, 18 Feb 2024 18:29:41 +0200 (EET) Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id CFDE168D36B for ; Sun, 18 Feb 2024 18:29:34 +0200 (EET) Received: by mail-pg1-f181.google.com with SMTP id 41be03b00d2f7-5cdf76cde78so2982244a12.1 for ; Sun, 18 Feb 2024 08:29:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708273772; x=1708878572; darn=ffmpeg.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=8zQ4SsEOjlqYeJAFap+lMtAQcv+raP+NY1WgLgoZKP0=; b=eaAuBRAv99tb8o7abO7fhOHeS+mq/8+uZYbTuWYw88wl6GD0oejTqmPuPQZVUgTWDm gJcDQKO+/79aHamHGhoRmLDnPRKp9CJ+nEUzk/C6l1D4TMu62Vm1JFbuMX65bCAp6DFG Bsqilt0HOneR6N3s5O9ZE8Pp49zqoOnHPhgSPK+7LpabpFliueJj7GjExKN8DU432llj CCYe3sgKPNplQyKpDEicj3BubHlTkGSb0XMp7LYK9WlPvDAWZNGskrPzUyLV1BlGz0vc foFoc7FfGGhl2bv0Xp6Qns4SgU86C2gGNfLNKihy5ZXGClAhDCrJYA4m6Q95gyBafZGo xirQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708273772; x=1708878572; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8zQ4SsEOjlqYeJAFap+lMtAQcv+raP+NY1WgLgoZKP0=; b=f3hAREBSbeFbYIeP9Xyu0sll5/QdM3vapFYELKe5KKbdmqPDQIpY9pEZqK0PcUPr2t y6+b4EpzXtQAcVDUykTiTMIkzLUdE56TFI6RIVGkdrFGQ8AGxQH6dC+8QfSLRwosxyBs X8WXRGwDJpGFtj0yBv5mb2WzOJrmnRt89KjqpyqTit0CBXg1kYj6lGWLLyaf+cp2r+7B KRAsmO94xwIoWu9UBwldJa2Sa6b4RARsCaW37dphmNoGcFQsZ925//akikftfsJS1qBc mnUHsJjSTaQwStjNyEWc8Nup4SUnvVkWWYcsQIg8bsehM4lxYqULro+x4m1ph2GyQcJf ABVg== X-Gm-Message-State: AOJu0YxJFZ7d+n0pIaH+/sB5CVcRg0H7CkCD5M3fskgRcHHc3Jno4Q4+ xn8e72undSwDlKNheWc8aTARjHcOagbyHq9oOv8oNUQnbwIV71l9Z3VNbZmQ X-Google-Smtp-Source: AGHT+IEaQTiM3wae6ixC+6MugvECbQ0temNJX6oaG5GSLoK4I/fDtHli9dda9eEcXeNVP5N1Niaq1g== X-Received: by 2002:a17:902:a516:b0:1db:51ee:8677 with SMTP id s22-20020a170902a51600b001db51ee8677mr7965985plq.59.1708273772189; Sun, 18 Feb 2024 08:29:32 -0800 (PST) Received: from [192.168.0.16] (host197.190-225-105.telecom.net.ar. [190.225.105.197]) by smtp.gmail.com with ESMTPSA id y9-20020a17090264c900b001d9a40f50c4sm2970514pli.301.2024.02.18.08.29.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 18 Feb 2024 08:29:31 -0800 (PST) Message-ID: <7c7d92bf-e7c6-451e-85ff-925772b5e6ea@gmail.com> Date: Sun, 18 Feb 2024 13:29:32 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20240218161636.15649-1-jamrial@gmail.com> From: James Almer In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH] avutil/mem: use C11 aligned_malloc() X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 2/18/2024 1:27 PM, Andreas Rheinhardt wrote: > James Almer: >> Save for the Microsoft C Runtime library, where free() can't handle aligned >> buffers, aligned_malloc() should be available and working on all supported >> targets. >> Also, malloc() alone may be sufficient if alignment requirement is low, so add >> a check for it. >> >> Signed-off-by: James Almer >> --- >> configure | 2 -- >> libavutil/mem.c | 42 ++++++------------------------------------ >> 2 files changed, 6 insertions(+), 38 deletions(-) >> >> diff --git a/configure b/configure >> index 7c45ac25c8..8fd2895ac2 100755 >> --- a/configure >> +++ b/configure >> @@ -6450,8 +6450,6 @@ if test -n "$custom_allocator"; then >> fi >> >> check_func_headers malloc.h _aligned_malloc && enable aligned_malloc >> -check_func ${malloc_prefix}memalign && enable memalign >> -check_func ${malloc_prefix}posix_memalign && enable posix_memalign >> >> check_func access >> check_func_headers stdlib.h arc4random_buf >> diff --git a/libavutil/mem.c b/libavutil/mem.c >> index 36b8940a0c..a72981d1ab 100644 >> --- a/libavutil/mem.c >> +++ b/libavutil/mem.c >> @@ -100,44 +100,14 @@ void *av_malloc(size_t size) >> if (size > atomic_load_explicit(&max_alloc_size, memory_order_relaxed)) >> return NULL; >> >> -#if HAVE_POSIX_MEMALIGN >> - if (size) //OS X on SDK 10.6 has a broken posix_memalign implementation >> - if (posix_memalign(&ptr, ALIGN, size)) >> - ptr = NULL; >> -#elif HAVE_ALIGNED_MALLOC >> +#if HAVE_ALIGNED_MALLOC >> ptr = _aligned_malloc(size, ALIGN); >> -#elif HAVE_MEMALIGN >> -#ifndef __DJGPP__ >> - ptr = memalign(ALIGN, size); >> -#else >> - ptr = memalign(size, ALIGN); >> -#endif >> - /* Why 64? >> - * Indeed, we should align it: >> - * on 4 for 386 >> - * on 16 for 486 >> - * on 32 for 586, PPro - K6-III >> - * on 64 for K7 (maybe for P3 too). >> - * Because L1 and L2 caches are aligned on those values. >> - * But I don't want to code such logic here! >> - */ >> - /* Why 32? >> - * For AVX ASM. SSE / NEON needs only 16. >> - * Why not larger? Because I did not see a difference in benchmarks ... >> - */ >> - /* benchmarks with P3 >> - * memalign(64) + 1 3071, 3051, 3032 >> - * memalign(64) + 2 3051, 3032, 3041 >> - * memalign(64) + 4 2911, 2896, 2915 >> - * memalign(64) + 8 2545, 2554, 2550 >> - * memalign(64) + 16 2543, 2572, 2563 >> - * memalign(64) + 32 2546, 2545, 2571 >> - * memalign(64) + 64 2570, 2533, 2558 >> - * >> - * BTW, malloc seems to do 8-byte alignment by default here. >> - */ >> #else >> - ptr = malloc(size); >> + // malloc may already allocate sufficiently aligned buffers >> + if (ALIGN > _Alignof(max_align_t)) >> + ptr = aligned_malloc(size, ALIGN); >> + else >> + ptr = malloc(size); >> #endif >> if(!ptr && !size) { >> size = 1; > > 1. The function is called aligned_alloc (how did you test this?). By compiling on a target with _aligned_malloc(), which hid my mistake. > 2. C11: "The value of alignment shall be a valid alignment supported by > the implementation and the value of size shall be an integral multiple > of alignment." Well, that sure is not very useful... > a) To use this, you would have to round size upwards; but this will make > sanitiziers more lenient. > b) If ALIGN is just not supported by the implementation, then everything > is UB in C11. > 3. What's the advantage of this patch anyway? Removing all the different target specific allocation functions in favor of the standard one. But your second point makes it moot, so patch withdrawn. > > - Andreas > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".