Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [omr-dev] Is this correct IL codegen?

Hi Mark,

Thanks very much for the detailed replies.

On 11 June 2018 at 15:42, Mark Stoodley <mstoodle@xxxxxxxxxx> wrote:
>
> > I guess part of the question is whether indirect load/store IL
> supports array offsets of the form base[index] or do I need to compute
> the address?
>
> The first operand of the indirect load/store for an array access is the address of the
> element that should be accessed. As such, it's up to the IL to do the multiplication
> of the index by the size of each element. We do that to give the compiler visibility
> of the calculations so it can optimize them where possible.
>
> So, if your "indexNode" parameters come in pre-multiplied, then it looks roughly
> right, though I confess I didn't check your code in great detail.

I have set it up so that the api expects the actual byte address of
the element, i.e. it assumes that element size has been accounted for.

> But I suspect you
> aren't expecting pre-multiplied indexNode parameters, so in that case you'll want
> to generate something like the following for the first child:
>         aiadd
>                <your base address>
>                 imul
>                         <your index>
>                         iconst <TR::DataType;:getSize(dt)>
>
> That's for 32-bit indices, of course. In a 64-bit system, you'd normally use aladd,
> lmul, and lconst . Depending on how flexible you want to be, you may need to
> do some integer conversion from the data type of your index node to the expected
> integer type of the index calculation (i or l). Make sense?

Yes, I saw how it was being done in IndexAt() method in ILBuilder. I
don't need the multiplication part as mentioned above - the caller is
expected to provide a byte address.

>
> You're probably working with C arrays, so no header to add in, but if there were one
> you would also have to add that into the first operand of the xaload|xastore .
>

Okay thank you for that info. I am dealing with plain structs, unions,
arrays etc - no magic. So that I can treat all of them as byte arrays
- my C front-end computes the field / element offsets etc.

Thanks and Regards
Dibyendu


Back to the top