From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id B2A9F3858031 for ; Tue, 12 Jan 2021 15:37:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B2A9F3858031 Received: by mail-ed1-x536.google.com with SMTP id p22so2760787edu.11 for ; Tue, 12 Jan 2021 07:37:20 -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:content-transfer-encoding; bh=/TuO/MQL03Y2u5HavWqSxV3oD4i4a7XxhJhH1JzxJbQ=; b=m2duN0fIV+U9pA1RpCP/6VR7onK6KPu5nx2qSHN5tB+wL9oMvVbqZ0kOuaBPZQC1Ta LAv/x4Ixnv7Hk+ylu9ybf2vNyVmTaOFLhakPqW9EmM2bI1yf8Enu7n+5rBkASqC5r0nh ANdeXgrBBrINTcXT+7LjP4Dg2w/r6aN7SUWlrVae4RLe5QhP5E0hI163+O6vTsndkbkj VVr1uOSNOnPhM4wSlm+4EMp3zZHMrt43jjRTpMu4ow9MtaBxYrLVrVYIi/zNG6f+nNbN 7VmYxymgVgS8W+CG/6o3PqUTKdaN/jq4tgFo7kEj3vr+voLdmzo8lyznPYxiHB91Kxqt 8p8Q== X-Gm-Message-State: AOAM5307e5wdA5X3L2SM/d5H26dOvxWA9XYljkB/FvPeroH02DKCQA8c 6eW3Ed1X9dscw8Scokq+DHDd0RNZSVtmhYbdSCU= X-Google-Smtp-Source: ABdhPJwVkERTA5i1Bjz61tGk4u64PwmCEDlLd/8Ye112ArqnUyGESlHaS39RF4LnWq9D2QerEWmPKaZSw55F9JWVRNw= X-Received: by 2002:a50:becf:: with SMTP id e15mr4060768edk.138.1610465839716; Tue, 12 Jan 2021 07:37:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Tue, 12 Jan 2021 16:37:09 +0100 Message-ID: Subject: Re: Adjust offset of array reference in named address space To: Tucker Kern Cc: Tucker Kern via Gcc , "Joseph S. Myers" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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 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: Tue, 12 Jan 2021 15:37:22 -0000 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 th= e correct instructions to read and "pack" the value into a register or gene= ric 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 s= pace. This doesn't feel like a far fetched idea as GCC currently supports a= ddress 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 wrote: >> >> On Sat, Jan 9, 2021 at 12:24 AM Tucker Kern via Gcc wr= ote: >> > >> > Hi, >> > >> > I'm implementing named addresses spaces for a Harvard architecture mac= hine >> > to support copying data from instruction memory to data memory. This i= s >> > achieved via a special instruction. e.g. think AVR and progmem/__flash= . >> > >> > However, the instruction memory is narrower than the data memory (12 v= s 16 >> > bits) on this machine. So a single data word is split across 2 instruc= tion >> > words. When copied from IMEM to DMEM the two parts are combined via SH= IFT + >> > 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 e= ach >> > array reference by 2. e.g. array[0] is actually stored in imem[0] & im= em[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 res= ort >> 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 o= ffset >> > 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