From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by sourceware.org (Postfix) with ESMTPS id BA2313858D20; Thu, 12 Jan 2023 02:46:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BA2313858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x1031.google.com with SMTP id o13so14267123pjg.2; Wed, 11 Jan 2023 18:46:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:subject:from:references:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=95V926DlNxY76f6SN8AdXBIzTOUbPGHy5hYw7dZKMXg=; b=jkIy2n5lv2tObinen2qSae4oWAHdoMFAQBfFpaIfOFvggWqJteZFav8FDgYZupN76z 0k0BCP1zJIThzGWH5wueq+BtcJ58e+tE/OI0Ods25kymHP8dOJu9TmedrJhE/cwpNlN9 ePJaE69ujp5NELFWmag37dSkFYSskxWg6PeD2rOGEqKy+x4XZt86OhNolzP2LKOTR+sw 1tQpiYTylvJjf+7gcpFEMH/tMgMVG0jRIQYDIQ3uL8zKKt6YSr8npbunJqwR0ls27TjU GQ+VJ5sXn3VBLRbhCq3jSXPkIHUQHSQCEKQSLigtdDLk6PBmBC3cqDy/o3tKqN7MM+5v odPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:from:references:cc:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=95V926DlNxY76f6SN8AdXBIzTOUbPGHy5hYw7dZKMXg=; b=0zvVW3M3RdFwj2sMJOP2GKvLHbS0fhF84C+ltZBK4bLjAG0tizcizWdh8cMBJQ0kNi 3dvtExgBNcDkqJ72JdYCI4GLEhle9qScqD2joV6xqFEx/kMQ5z4Ndr8EMkkg1Z12Ls3U StesTSwFu2rFEOmxGptUAQtEfftfJyr9nO53ucLWLorwj7Uws72C3EW97gRxbSr3U3Lm b91pD99q6z0ZmFWsTKi+GMhi4ohySq/+MngKyN2RiIu+jlrmnlqxUw3V/sn42NBhrotS GMykmp3pQ0zkQbQBS9Nc186Eoss/hMs8wgBjGr8YwAHOxGoLoUOG1NEIyTkmst26wHdA ni0A== X-Gm-Message-State: AFqh2kqYhoMJN2w/1m8H4jkR3/9RIsZmHfXbPQAe710QS9jBrkEVDU0B i49vudfsX4/+gNxb3Ji6rlw= X-Google-Smtp-Source: AMrXdXu4rigpK5Ym0noTk/l0OgN6sWUq3AZZLQBjPWYYhDFnbHoqatNegQA7Btmoz647ThYqQVXvng== X-Received: by 2002:a17:90a:f104:b0:227:c6c:bdb3 with SMTP id cc4-20020a17090af10400b002270c6cbdb3mr3343735pjb.4.1673491572777; Wed, 11 Jan 2023 18:46:12 -0800 (PST) Received: from [192.168.1.20] ([50.37.188.226]) by smtp.gmail.com with ESMTPSA id m12-20020a634c4c000000b0047063eb4098sm8964691pgl.37.2023.01.11.18.46.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Jan 2023 18:46:12 -0800 (PST) Message-ID: Date: Wed, 11 Jan 2023 18:46:11 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Content-Language: en-US To: Thomas Schwinge , Richard Biener , Tom de Vries , gcc-patches@gcc.gnu.org Cc: Janne Blomqvist , fortran@gcc.gnu.org, Alexander Monakov References: <87mtaigz3l.fsf@dem-tschwing-1.ger.mentorg.com> <87zgcxoa05.fsf@euler.schwinge.homeip.net> <87ili2p60p.fsf@euler.schwinge.homeip.net> <87cz7ll1hh.fsf@euler.schwinge.homeip.net> From: Jerry D Subject: Re: [PING] nvptx: '-mframe-malloc-threshold', '-Wframe-malloc-threshold' (was: Handling of large stack objects in GPU code generation -- maybe transform into heap allocation?) In-Reply-To: <87cz7ll1hh.fsf@euler.schwinge.homeip.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 1/11/23 4:06 AM, Thomas Schwinge wrote: > Hi! > > Ping -- the '-mframe-malloc-threshold' idea, at least. > > Note that while this issue originally did pop up for Fortran I/O, it's > likewise relevant for other functions that maintain big frames, for > example in newlib: > > libc/string/libc_a-memmem.o:.local .align 16 .b8 %frame_ar[2064]; > libc/string/libc_a-strcasestr.o:.local .align 16 .b8 %frame_ar[2064]; > libc/string/libc_a-strstr.o:.local .align 16 .b8 %frame_ar[2064]; > libm/math/libm_a-k_rem_pio2.o:.local .align 16 .b8 %frame_ar[560]; > > Therefore a generic solution (or, workaround if you'd like) does seem > appropriate. > ---snip --- AS a gfortranner I have to at least say anyone doing fortran I/O on a GPU is nuts. With that said, a configurable option to address the broader issue makes sense. Perhaps the default threshold should be whatever it is now and if someone has a real situation where it is needed, they can adjust. Regards, Jerry