From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x34.google.com (mail-oa1-x34.google.com [IPv6:2001:4860:4864:20::34]) by sourceware.org (Postfix) with ESMTPS id 1B6DB3858D37 for ; Thu, 30 Nov 2023 04:13:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1B6DB3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1B6DB3858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:4860:4864:20::34 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701317629; cv=none; b=l8gFupIJeJ4GgDkPAJRsizCxWAz0cGTgCbyb/OPjKH56x14UZENdRVXVbCLl1aMrsgkex0gIcBp/KNKRXa0B9Wh8r3wudLT4L44h8Fy0Q5LtgZqcYoFoNDUqcflGpdTbaN8Q9EaAFSttJoPFXvwaOhjJfJL9SYXY5ECjzZ2UnWI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701317629; c=relaxed/simple; bh=oFjSKmaLIqTtDUC7Mxoe3bcbfFqKej+QC/FJJJmxzAA=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=WtXhn+fmbjlzhA44Ylvaydgdl/4UWELOH3IuF8xD4aeo0BUtarki99DGmuKd6YwLgqHCnRDHTwqrod7H8a7WjOjb+x9lMbZXd7X7kzHzyjwkAK2zvHx2m1N/bD4tmOfBWivVrXMiP1jMMD3xcXbaOEsVvV/fe9Pe35IyMB5WKMs= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-1f03d9ad89fso238713fac.1 for ; Wed, 29 Nov 2023 20:13:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1701317626; x=1701922426; darn=gcc.gnu.org; h=mime-version:user-agent:message-id:in-reply-to:date:references :organization:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=bGOvqWU9AVOF5kcc6/YVSbQH1G0r/DAlfY9a+UeAlP8=; b=blwHoXrO/VLedv1461Rd0Yp7/kbZPEUgPNBD88gGuzdk4wWvyLqwNh4OIF0TpvTHYh 329E61tnvAOcTDFBbfxvecQstxGQhxSQ728TuLCVIusbD6nNGvYg7DLhuEFRC/pr3Nbo EI7oRxWisj1Quf+IFtD+tEQmexRTKonUu6TccE9K16zdKbg9x7/OVw4+JX0qB3tPPMWV MLHS0y0kjS30zVOVoyb4uFsSteCT+QxskV3dPxgIhR63lATWy7r1EL7b56TVugJy4PJ+ yWkReDCb07c8u7Ejo37p2GfPcB/YUZbAGNgsU//skhZkTpGGEWoGruCWkgnHCf5g6G/O eJNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701317626; x=1701922426; h=mime-version:user-agent:message-id:in-reply-to:date:references :organization:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bGOvqWU9AVOF5kcc6/YVSbQH1G0r/DAlfY9a+UeAlP8=; b=w3lCfRw1QE+GfMfU98sUBGEI2/DIvCKtVdK/fvToHRcCyDQdlddZ2lxGk6RYnaYHB6 cyDQaX/MCn/V9d/wv20BPoOI3JA9nfoXaD8nn9SH2qlI2Az+cBeq00TUfjriKjPjDCDo m+DPWwNzOvS4w23ZyH69NTRcTYpCHGSMktk8jOvo4vx4Q7Su5gHABZ0HJ+3Tvs2plt5r ll1yyEgSp7H606Tn473UTJXpRD3cYELyevB/Z0AycXN0q6iKqTIjl+rRotPWYa9vOhnx cYYGcQwjVb9fUTLrxuQzBJvEFOzfyNdvC6k3lgQgpNWIbzw6PWpO6Seqoj1DOvJqW8rX OxeQ== X-Gm-Message-State: AOJu0Yz/DjZNa3VW4whUuIyIczpaWnscW2gPI2vwDZDklpMPpJGcrKCB STLqpdMCn9DWIvKP+sl6DpRwBQ== X-Google-Smtp-Source: AGHT+IGlA6P0n3u+dwWnic3g2A7gY6+NZG1SOPDP8hRyVcWLZB6uXKZypIOddvM5qebfPlAmo+Zr7A== X-Received: by 2002:a05:6870:b526:b0:1fa:bd89:acd with SMTP id v38-20020a056870b52600b001fabd890acdmr1794366oap.26.1701317626310; Wed, 29 Nov 2023 20:13:46 -0800 (PST) Received: from free.home ([2804:7f1:2080:8d38:553a:9121:2785:9c36]) by smtp.gmail.com with ESMTPSA id gu26-20020a056a004e5a00b006cbb65edcbfsm207546pfb.12.2023.11.29.20.13.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Nov 2023 20:13:45 -0800 (PST) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 3AU4DWHG049177 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 30 Nov 2023 01:13:33 -0300 From: Alexandre Oliva To: Richard Biener Cc: gcc-patches@gcc.gnu.org, Jeremy Bennett , Craig Blackmore , Graham Markall , Martin Jambor , Jan Hubicka , Jim Wilson , Jeff Law , Jakub Jelinek Subject: Re: [PATCH v4] Introduce strub: machine-independent stack scrubbing Organization: Free thinker, does not speak for AdaCore References: Date: Thu, 30 Nov 2023 01:13:31 -0300 In-Reply-To: (Richard Biener's message of "Wed, 29 Nov 2023 13:48:41 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 X-Spam-Status: No, score=-12.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,WEIRD_QUOTING autolearn=unavailable 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 Nov 29, 2023, Richard Biener wrote: >> Because &arg_#(D)[n_#] is good gimple, but &(*byref_arg_#(D))[n_#] isn't. > 'arg_#(D)' looks like a SSA name, and no, taking the address doesn't work, > so I assume it was &MEM[arg_(D)][n_#] which is indeed OK. Yeah. > But you shouldn't need to change a pointer argument to be passed by > reference, do you? True, my attempt to simplify the example moved it past the breaking point. IIRC the actual situations I hit involved computing address of members of compound objects, such as struct members, even array elements thereof. They became problematic after replacing the object with a dereference in gimple stmts. The (effectively) offsetting operation is well-formed gimple, but IIRC adding dereferencing to it made it malformed gimple. I don't immediately see why this should be the case, since it's still offsetting, so perhaps I misremember. > As said, you want to restrict by-reference passing to arguments > that are !is_gimple_reg_type () *nod*, it was already there: if (!(0 /* DECL_BY_REFERENCE (narg) */ || is_gimple_reg_type (TREE_TYPE (nparm)) ... { indirect_nparms.add (nparm); >> Here are changes.html entries for this and for the other newly-added >> features: > LGTM. Was that an ok to install, once the relevant pieces are in? > Can you check on the pass-by-reference thing again please? Sure. I'll get back to you shortly. If argument indirection becomes the only blocking issue, I'd be happy to disable it, or even split out the patch that introduces it, so that the bulk of the feature can go in while we sort out these details. Disabling it is as simple as: diff --git a/gcc/ipa-strub.cc b/gcc/ipa-strub.cc index 293bec132b885..90770202fb851 100644 --- a/gcc/ipa-strub.cc +++ b/gcc/ipa-strub.cc @@ -2831,6 +2831,7 @@ pass_ipa_strub::execute (function *) parm = DECL_CHAIN (parm), nparm = DECL_CHAIN (nparm), nparmt = nparmt ? TREE_CHAIN (nparmt) : NULL_TREE) + if (true) ; else // ??? Disable parm indirection for now. if (!(0 /* DECL_BY_REFERENCE (narg) */ || is_gimple_reg_type (TREE_TYPE (nparm)) || VECTOR_TYPE_P (TREE_TYPE (nparm)) > Let's see if Honza or Martin have any comments on the IPA bits, I just > mentioned what I think should be doable ... I'm curious as to what you're hoping for. I mean, I am using create_version_clone_with_body, adding the new params and copying the preexisting ones, and modifying some argument types for indirection after cloning. The problems I faced were as I tried to replace params with their indirected versions. According to my notes and my recollection, that's where I hit most of the trouble. But what would this really buy us? Do you envision a possibility of actually splitting out the original function body, so that IPA takes care of the whole wrapping? AFAICT that would require a lot more infrastructure to deal with new and modified parameters, though the details of what I learned about this API back then, and that made it clear I wouldn't be able to use it, seem to have faded away from my memory. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive