On Fri, Sep 15, 2023 at 11:20 AM Thomas Schwinge <tho...@codesourcery.com> wrote: > > Hi! > > Now, that was another quirky debug session: in > 'gcc/omp-low.cc:create_omp_child_function' we clearly do set > 'TREE_USED (t) = 1;' for '.omp_data_i', which ends up as formal parameter > for outlined '[...]._omp_fn.[...]' functions, pointing to the "OMP blob". > Yet, in offloading compilation, I only ever got '!TREE_USED' for the > formal parameter '.omp_data_i'. This greatly disturbs a nvptx back end > expand-time transformation that I have implemented, that's active > 'if (!TREE_USED ([formal parameter]))'. > > After checking along all the host-side OMP handling, eventually (in > hindsight: "obvious"...) I found that, "simply", we're not streaming > 'TREE_USED'! With that changed (see attached > "Re-introduce 'TREE_USED' in tree streaming"; no visible changes in > x86_64-pc-linux-gnu and powerpc64le-unknown-linux-gnu 'make check'), my > issue was quickly addressed -- if not for the question *why* 'TREE_USED' > isn't streamed (..., and apparently, that's a problem only for my > case..?), and then I found that it's *intentionally been removed* > in one-decade-old commit ee03e71d472a3f73cbc1a132a284309f36565972 > (Subversion r200151) "Re-write LTO type merging again, do tree merging". > > At this point, I need help: is this OK to re-introduce unconditionally, > or in some conditionalized form (but, "ugh..."), or be done differently > altogether in the nvptx back end (is 'TREE_USED' considered "stale" at > some point in the compilation pipeline?), or do we need some logic in > tree stream read-in (?) to achieve the same thing that removing > 'TREE_USED' streaming apparently did achieve, or yet something else? > Indeed, from a quick look, most use of 'TREE_USED' seems to be "early", > but I saw no reason that it couldn't be used "late", either?
TREE_USED is considered stale, it doesn't reflect reality and is used with different semantics throughout the pass pipeline so it doesn't make much sense to stream it also because it will needlessly cause divergence between TUs during tree merging. So we definitely do not want to stream TREE_USED for every tree. Why would you guard anything late on TREE_USED? If you want to know whether a formal parameter is "used" (used in code generation? used in the source?) you have to compute this property. As you can see using TREE_USED is fragile. > Original discussion "not streaming and comparing TREE_USED": > <https://inbox.sourceware.org/alpine.lnx.2.00.1306131614000.26...@zhemvz.fhfr.qr> > "[RFC] Re-write LTO type merging again, do tree merging", continued > <https://inbox.sourceware.org/alpine.lnx.2.00.1306141240340.6...@zhemvz.fhfr.qr> > "Re-write LTO type merging again, do tree merging". > > > In 2013, offloading compilation was just around the corner -- > <https://inbox.sourceware.org/1375103926.7129.7694.ca...@triegel.csb> > "Summary of the Accelerator BOF at Cauldron" -- and you easily could've > foreseen this issue, no? ;-P > > > Grüße > Thomas > > > ----------------- > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 > München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas > Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht > München, HRB 106955
