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 <richard.guent...@gmail.com>
wrote:
> On Tue, Jan 12, 2021 at 4:29 PM Tucker Kern <tuckk...@gmail.com> 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.guent...@gmail.com> wrote:
> >>
> >> On Sat, Jan 9, 2021 at 12:24 AM Tucker Kern via Gcc <gcc@gcc.gnu.org>
> 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
>
