From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) by sourceware.org (Postfix) with ESMTPS id E397C3894C35 for ; Thu, 14 Jan 2021 03:56:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E397C3894C35 Received: by mail-vs1-xe2b.google.com with SMTP id o19so2401306vsn.3 for ; Wed, 13 Jan 2021 19:56: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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lNJM/l6WZaz8//RheWPk1TTz881Bxgr989HCCvuASP8=; b=l2aQ2KKB3aEnNTWjNuYvDjcXUejP5NTK0r9ymxvYBy/TNweoiOrxZx3fcuEf5O5WGf NyZWpEtHZdh3vPEqSiy/7cy8DoUgFk6ajN+9n5KmGcdlrVkirguFELtX5ur8AfV8DVLe m2zczeVqmUeDoq++u8r4dj8f046oDX5Z9oFwv5O1/UQ7PsJlIECtfQnYNkqL3r33LjiT 4wR8QHvnGF+6CmniXC0XORoNs+cSPY9PqIjYvJhDIZ7nnPSSAb7PUZsgsqt8lY3fYRrA AcxL97+iCanT9aW99qtNvIZDUppDLUHGzlf3dUMN1wSwiRqwYNWq94a1mkocHF/++ICe f/dA== X-Gm-Message-State: AOAM531SOZjBQCZe9QWuj9bafJHcZgj/UpdQZ2HTx2qUvkvtPxeNrftz ABtwhB2p1RltJm1uKqJUFDNkqVlr6e6QYJhKzyM= X-Google-Smtp-Source: ABdhPJwd/xw3yDGH8FFeC7w2lxUsTLtvNE8kXfbnTmOb2awFWutxTFn+vRdl7hSH4VR8QJZoOpk/EfmOSNNBA+JkrtU= X-Received: by 2002:a67:e155:: with SMTP id o21mr5254873vsl.47.1610596591439; Wed, 13 Jan 2021 19:56:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tucker Kern Date: Wed, 13 Jan 2021 20:56:19 -0700 Message-ID: Subject: Re: Adjust offset of array reference in named address space To: Richard Biener Cc: Tucker Kern via Gcc , "Joseph S. Myers" X-Spam-Status: No, score=-3.6 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: Thu, 14 Jan 2021 03:56:33 -0000 Richard, As always thanks for the insight. I'll take a look at those functions as well. -Tucker On Tue, Jan 12, 2021 at 8:37 AM Richard Biener wrote: > On Tue, Jan 12, 2021 at 4:29 PM Tucker Kern wrote: > > > > > So you are saying that a 16bit data word in IMEM is actually two 12bit > > > data words (supposedly only the lower 8 bits used in each) and thus the > > > array contains "padding"? > > > > Effectively yes. The assembler handles dividing constants into their LSB > and MSB components. I have insn patterns and splitters defined that emit > the correct instructions to read and "pack" the value into a register or > generic memory location. > > > > All I really need at this point is a means to augment how addresses > (e.g. array offsets or struct members) are calculated in a non-generic > address space. This doesn't feel like a far fetched idea as GCC currently > supports address space specific legitimization and modes. > > I think you'd need to hook this up in structure layouting which then > runs into the issue that > the address space is a qualifier and GCC internals expect layouts to > be compatible between > qualified and unqualified types. Also all target hooks in the layout > code mostly deal with > bitfields only. > > The offset is computed via get_inner_reference from expand_expr_real_* > so I don't > see a good way to handle this correctly. But maybe Joseph has an idea. > > Richard. > > > On Mon, Jan 11, 2021 at 12:50 AM Richard Biener < > richard.guenther@gmail.com> wrote: > >> > >> On Sat, Jan 9, 2021 at 12:24 AM Tucker Kern via Gcc > wrote: > >> > > >> > 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]. > >> > >> So you are saying that a 16bit data word in IMEM is actually two 12bit > >> data words (supposedly only the lower 8 bits used in each) and thus the > >> array contains "padding"? That's not really supported and is also not > >> the scope of named address spaces. I'd suggest you go down the route > >> of providing intrinsics for the transfer of data instead which could > resort > >> to target specific builtin functions. > >> > >> > 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 >