From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) by sourceware.org (Postfix) with ESMTPS id CB7943858C00; Fri, 11 Nov 2022 14:39:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CB7943858C00 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-wm1-x32e.google.com with SMTP id t4so3048352wmj.5; Fri, 11 Nov 2022 06:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=X3d+a1MrF5SDVh3OCsocXX6QqwXNU2KxqWpg0GNx8lI=; b=DfV68b76VFvzltVqQpOPBvvv3/OWOscyJeU8i7URkpQIGaWXH3jOWv1GYIWDPxaCP0 +bEnpvA6O/37yrcWXsCqthYEKWaD3PmAbamOPTE9AEHQFQgSp1JSPjPgf6e1lDvvgN8r kQ7T8lE6svo3GvSfm94lXuKM8VAv6pDScPexHUCpogTfBsici8J1R3sNvLUSdWFfD0WP vPs7tgRQ6jU3p+m0jZ2h8Z7m8zg39hkKp0TF3a8HuKd9RX8/+UPVXa2repbae/Kv7Lag Pcv9HN6/IK0BFVVhW+YsNOxy0X/6Uwvx/gcfuMjhtpRXfdl1J5enyUU1D3UdoPDC5U70 quDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=X3d+a1MrF5SDVh3OCsocXX6QqwXNU2KxqWpg0GNx8lI=; b=Qv+soHt7JJr+bLLgh+C6JBDnOIoLIk9IxZcthu0ebr4WKj9+RQZu0NPhs3mRAlP0Jw Re8U5C9xgqq5TQwhzhA7z878EsZSwZ/I5LKB6qNnaA7k5iGl5i2Fz3bVAvYgQHuUhmgN 9IaDd0MsRkg5ZqVlyxFd8MXfM09MJ4dDRsdh01tuEnsRgIFUzNrZTm+TyGZkj/sMgh7q 8o/aHzSbnt4+YZdFedMRMLVnD+JXYHweMzSLpkC45rxPqrewD0ajVVZDaSHQS/1svaT3 2LWZg1FFNMVa+SdcI6LgqFNiFysu0lEfNR5LmMGIcCU3djHueW21inwWVj5j2AcQLg9v DSTg== X-Gm-Message-State: ANoB5pktxYtkFwo6yqaAlxbnD9ivntQ1z/jhykbYJrMUsjMaZSsMJUQ5 W/+oavSC1PXyHPvS9T7WFB9lrcHsS4Fnc3J2ga4= X-Google-Smtp-Source: AA0mqf62pgM1VWldINLlwBuHV25wGK/NDB5MaYxflWyk4Jx1o5i0NZ8qX/F6tcH2PJnSNmd1WHh1q/XFvA8bbfJI4HI= X-Received: by 2002:a05:600c:18a3:b0:3cf:a895:a9cb with SMTP id x35-20020a05600c18a300b003cfa895a9cbmr1451733wmp.96.1668177545550; Fri, 11 Nov 2022 06:39:05 -0800 (PST) MIME-Version: 1.0 References: <87mtaigz3l.fsf@dem-tschwing-1.ger.mentorg.com> <87zgcxoa05.fsf@euler.schwinge.homeip.net> In-Reply-To: <87zgcxoa05.fsf@euler.schwinge.homeip.net> From: Janne Blomqvist Date: Fri, 11 Nov 2022 16:38:54 +0200 Message-ID: Subject: Re: Handling of large stack objects in GPU code generation -- maybe transform into heap allocation? To: Thomas Schwinge Cc: fortran@gcc.gnu.org, gcc@gcc.gnu.org, Tom de Vries , Alexander Monakov Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,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 Fri, Nov 11, 2022 at 4:13 PM Thomas Schwinge wrote: > For example, for Fortran code like: > > write (*,*) "Hello world" > > ..., 'gfortran' creates: > The issue: the stack object 'dt_parm.0' is a half-KiB in size (yes, > really! -- there's a lot of state in Fortran I/O apparently). > Any other clever ideas? There's a lot of potential options to set during Fortran I/O, but in the vast majority of cases only a few are used. So a better library interface would be to transfer only those options that are used, and then let the full set of options live in heap memory managed by libgfortran. Say some kind of simple byte-code format, with an 'opcode' saying which option it is, followed by the value. See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48419 for some rough ideas in this direction, although I'm not personally working on GFortran at this time so somebody else would have to pick it up. -- Janne Blomqvist