From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) by sourceware.org (Postfix) with ESMTPS id 25A2A38438A4 for ; Fri, 8 Jan 2021 23:23:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 25A2A38438A4 Received: by mail-qk1-x733.google.com with SMTP id z11so10019241qkj.7 for ; Fri, 08 Jan 2021 15:23:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HfsjuNUCmVw5BGQZfn6qdyXo57yUTRJMRvE5fNl9vLY=; b=rgCTLMBxgWPY9wAtKrdT/vRVPGVFBGKUZf/h6xXN2X1Q5SSeCsn9o8bPAJn6s6La10 KLyux8viv5MrX6OQ7Afizy/0yxdM8sDsOa5l97Grugeiofa8iOxiKeUdELdvTnMFjoa3 1oFmzLfB0bM7rHyBYNp0pptg0JNeQeDvd6ct+0yTMI5x6XyJtjD3CIlQfka9smnZlg/s bnwxHdF06D0CXbdIQ2rA5RBtsOdQZ1EwjdbYdqI3XPPY8WBZXT8f07L7V2o7BIhR/2C0 G02E370XDJ+GAbPDekIei5fJe4DvIOqw7N0xV+966YldRurHsAgKJ31CS+B/kqnyLKp2 Ui0A== X-Gm-Message-State: AOAM530S8auv6zY3flTLr0jtTTeFl897C8ubHxLVO1WvEQysmYRe7e+/ CD31thVJFpvhYJMakFGO7yEkfKKRYWD53lkZwFYp5mS9qqMJ3Q== X-Google-Smtp-Source: ABdhPJzPc1BZAOhr3APYJ0upbV2RBbfOrpmrfLXeHkpDp5/3SIGl4jCDNEe0NwTsRo/UsXWCVVLMm0GpjEnRARmLtOM= X-Received: by 2002:a37:a1d6:: with SMTP id k205mr6321637qke.384.1610148210551; Fri, 08 Jan 2021 15:23:30 -0800 (PST) MIME-Version: 1.0 From: Tucker Kern Date: Fri, 8 Jan 2021 16:23:19 -0700 Message-ID: Subject: Adjust offset of array reference in named address space To: Tucker Kern via Gcc X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 23:23:38 -0000 Hi, I'm implementing named addresses spaces for a Harvard architecture machine to support copying data from instruction memory to data memory. This is achieved via a special instruction. e.g. think AVR and progmem/__flash. However, the instruction memory is narrower than the data memory (12 vs 16 bits) on this machine. So a single data word is split across 2 instruction words. When copied from IMEM to DMEM the two parts are combined via SHIFT + OR patterns. This is all working fine for regular variables (i.e. int som_var), but it falls apart for array references (i.e. some_array[1]). Since the data is stored across 2 IMEM words, I need to scale the calculated offset of each array reference by 2. e.g. array[0] is actually stored in imem[0] & imem[1] and array[1] is stored in imem[2] & imem[3]. e.g. static __imem int imem_array[2]; return imem_array[1]; // needs to generate a symbol reference like &imem_array.869+2 Similarly if the array index was a function parameter, I need to scale the parameter by 2. __imem int imem_array[2]; int some_func(int a) { // a needs to be scaled by 2 when generating RTL/ASM return imem_array[a]; } I haven't found any target hooks that would allow me to override the offset calculation. Originally I thought I could handle it in a splitter but this approach didn't work for the function parameter example as I ended up scaling the entire address instead of just the offset. I had another thought of using a combo of TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS and TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P to scale the offset and mark it as adjusted but I don't think this combo will work in the end. Is there any way to achieve this? Thanks, Tucker