From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id A961D3858428 for ; Tue, 25 Apr 2023 10:45:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A961D3858428 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1682419506; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=gEW4ks1lu+L7yurqB6/5WmKOTQCwwJsaKf7Kzv7j46A=; b=Z7qhbD812cL7blrJtUVDjGN4fRBJRdsBjmO7XJVEGly21oDhD826VnHoTvPUkAtqFZPQvp yEIbCubCckRGN7gDUg3MkPCl3wG0frtwhK0E2NjQvNM8Ce9OtZEdvpaPzJwGyvPsv1jR72 29WEHF148d6SrnQv7AawAKkcryDZ7aE= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-86-3aLYs_tfOQK13NKC6tirkw-1; Tue, 25 Apr 2023 06:45:04 -0400 X-MC-Unique: 3aLYs_tfOQK13NKC6tirkw-1 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-3f1754de18cso32415165e9.1 for ; Tue, 25 Apr 2023 03:45:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682419503; x=1685011503; h=content-transfer-encoding:subject:from: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=gEW4ks1lu+L7yurqB6/5WmKOTQCwwJsaKf7Kzv7j46A=; b=eFgF1HltnW+1Oyjn8ICFY5/Oal6fv129ifSN4ckDqrtYpwSLhB9EX/TaifzmLjy2Md eLTElar6YI47lnso+6B6sLe5uHdliZsVkzHF1ZL9Wjzpeqtdb/TS6SLZy6taAOiCiNXK a8PFAxcViM0wGhHAcustcVh5RG9+C4YSVy5yHQpwI+gGnjBN4IRgOZhr/wlBOQ2IU3N0 ddyyKAcGbOmQB4rcn1iD7SrB80glG8mldFCAKSKiwnrgVw1ynFjGAVS83h8L8wQeO2Jz v1+yysDxXBlpshYLTK+KSV4Ln9uCxqF2hMGToaPfG/OfJHPIEhQpQKAjbZLsUgjQS62H HDTg== X-Gm-Message-State: AAQBX9dloLwPG1oulC6h5dje2mK8BzaGH9EFFSiBRmLPj7jLHo9h0YYH 4ApDRanVe0kM30NOClBZvQT/7otCpXY7M0G3K6D9y7R8t3Uu08nZA7Ni/CGGRsI+V3VROAIJIc7 qGf7XhQv90mBwUJbKRNDuNl0EHloFpYDWfxyECitEC1t6UqIDMhIr5orF33yLyH4= X-Received: by 2002:a5d:5960:0:b0:2f9:9f6f:e4d with SMTP id e32-20020a5d5960000000b002f99f6f0e4dmr10164608wri.39.1682419503482; Tue, 25 Apr 2023 03:45:03 -0700 (PDT) X-Google-Smtp-Source: AKy350b8hdkWLoAIk7tqGylCFn53hH8tpsFVSgLmuWbt1kwL8ZKA37Cike9BmIdAXrTkXtEOZp3E2Q== X-Received: by 2002:a5d:5960:0:b0:2f9:9f6f:e4d with SMTP id e32-20020a5d5960000000b002f99f6f0e4dmr10164592wri.39.1682419503105; Tue, 25 Apr 2023 03:45:03 -0700 (PDT) Received: from [192.168.1.201] ([139.47.42.170]) by smtp.gmail.com with ESMTPSA id v15-20020a05600c444f00b003f09cda253esm18162677wmn.34.2023.04.25.03.45.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Apr 2023 03:45:02 -0700 (PDT) Message-ID: Date: Tue, 25 Apr 2023 12:45:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 To: GCC Mailing List Cc: Andrew MacLeod , Richard Biener From: Aldy Hernandez Subject: Upcoming removal of legacy ranges and conversion to wide_ints. X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: After GCC 13 is released we will remove legacy range support from the compiler, and convert irange's to wide_ints. I want to give everyone a heads up, to help understand what's involved and what the end result is. Legacy ranges are basically the value_range type (int_range<1>) where the internal representation has anti-ranges and allows symbolics, etc. It is a holdout from the old VRP, and was left in place because it was pervasive and too risky remove late in the GCC 13 cycle. There will be lots of patches (about 30), mostly because legacy touches a lot, and also because it was necessary to rip out things in order to double check the work. Furthermore, having small pieces makes it easier to bisect any possible regressions. I will give a bird's eye view of what follows with details in the patches themselves. First the good news. VRP improves by 13.22%, jump threading by 11.6% and overall compilation improves by 1.5%. Andrew has some improvements to the cache that should provide significant additional speedups. Here are the main parts of the work: 1. Converting users of the old API to the new irange API. There are a few holdouts, most notably the middle end warnings, some of which have strong dependencies on VR_ANTI_RANGE and the old API. I have provided a transitional function (get_legacy_range) which translates an irange to whatever min/max/kind concoction they rely on. I have no plans for converting these passes, as I don't understand the code well enough to fix it. Naive attempts broke the tests, even though conceptually the changes were correct. At least the damage will be limited to users of one function: get_legacy_range(). The IPA passes also use the old API, but I have plans (and patches) for revamping all of the IPA ranges. Details below. 2. Repurposing int_range<1> to its obvious meaning (a range with two endpoints). This will reduce the memory footprint for small ranges. 3. Overhauling the vrange storage mechanism used for global ranges (SSA_NAME_RANGE_INFO) so it can be shared with the ranger cache. The reason for this is because the ranger cache used a tree range allocator, which didn't exactly scale to the eventual conversion to wide ints. It also allows us to use one lean and efficient allocator for everything instead of two incomplete implementations. The storage remains slim (no trees, plus a trailing_wide_int like implementation). The storage is also quite fast, since without legacy or trees, we can copy host integers arrays back and forth between the storage and the wide_ints. 4. Conversion of trees to wide ints in irange. 5. Various performance optimizations now possible because we have moved away from both legacy and trees. A few notes. The value_range typedef has been renamed to int_range<2>, since int_range<1> now means two endpoints which can't represent the inverse of a range (say not-zero) for anything but a handful of ranges. The (future) plan is to mechanically convert the definitions to int_range<2> and finally rename Value_Range (the type agnostic range class) to value_range for use in passes that must work in a variety of different types (floats, integers, etc). IPA has been rolling their own ranges forever. They use a combination of the legacy API along with handcrafted pairs of wide_ints (ipa_vr). The passes must be divorced of its legacy dependency, and cleaned up a bit. IPA is also very tied to integers and pointers, and I see no reason why we can't keep track of float arguments, etc. I am sitting on a lot of additional patches to do 90% of the conversion, but need to consult with the IPA experts on various issues before proceeding (for instance, the lifetime of various structures). Among these patches are generic vrange LTO streaming functions and vrange hashing. I think it's time we make vrange a first class citizen for LTO/hashing and a few other things folks were doing in an ad-hoc manner. This should alleviate the maintenance burden on the IPA maintainers going forward. Note, that the IPA work is a follow-up, and only after careful consultation with the relevant maintainers. In addition to the IPA/LTO work described above, future work this cycle will include converting irange to the value/mask mechanism we use elsewhere in the compiler (CCP, etc). With wide ints in place, this should be relatively straightforward, plus it will give us additional optimization opportunities in the ranger ecosystem. Comments welcome. Aldy and Andrew