Re: [omr-dev] Symbol refs, shadow refs and aliasing

[Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx>]

Hi Vijay

Thank you for the insights - much appreciated. Some follow up questions below.

On 4 July 2018 at 22:04, Vijay Sundaresan <vijaysun@xxxxxxxxxx> wrote:
> Answers to some of your questions :
>
> 1. Yes.
> In theory the optimizer ought to be able to change aggregate fields and
> aggregate array elements into local variable accesses where beneficial, but
> I don't think it will happen in every case (certainly not at <= warm opt
> level).
> The closest the optimizer will get to doing that kind of a transformation
> would be in PRE but that would effectively be "globally commoning" the
> values of the accesses you are concerned about as opposed to some sort of
> replacement of the aggregate accesses by N locals instead that get mapped to
> the N locations that corresponded to the different fields within the
> aggregate.
> In general, the optimizer handles local variables much better than indirect
> accesses based on shadows; classic example would be GRA which only considers
> locals and parms for assignment.
>
> 2. Yes.
> A general rule would be to represent as a local variable as an auto in the
> IL as early as possible. Even if the optimizer cleaned everything up
> eventually it may be too late for running some opt pass that may have
> benefited from seeing local variables as autos. So, I would suggest
> representing local variables as simply as possible (auto being the natural
> way to do) to get any sort of decent optimization.

Okay understood.

>
> For questions >= 3
> I'd prefer if shadows/aggregates were not used at all to represent locals.
> So I wonder if those questions needs to be answered at least in this thread.
>

Is there an alternative way to create a local value that is bigger
than a primitive? I am using OMR as JIT for C backend - so there can
be local vars that are structs, unions or arrays. I saw that in
JitBuilder a byte array type is used to represent structs / locals -
which made sense to me - i.e. a C struct is just a region of memory
that in interpreted in a certain way. What would be the alternative
way to represent such local values?


> Thanks,
>
> Vijay Sundaresan
> STSM, WAS and Runtimes Performance Architect
> IBM Toronto Lab
> Email : vijaysun@xxxxxxxxxx
> Phone : 905 413 3797 Fax : 905 413 4854
>
>
> Dibyendu Majumdar ---07/02/2018 03:00:06 PM---Hi, Now that I have the basic
> JIT backend working I want to address an
>
> From: Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx>
> To: omr developer discussions <omr-dev@xxxxxxxxxxx>
> Date: 07/02/2018 03:00 PM
> Subject: [omr-dev] Symbol refs, shadow refs and aliasing
> Sent by: omr-dev-bounces@xxxxxxxxxxx
>
> ________________________________
>
>
>
> Hi,
>
> Now that I have the basic JIT backend working I want to address an
> area that is deficient in my implementation. This is to do with how
> local stack values are handled. Currently I am defining all local vars
> as byte arrays and using array store/load ops but I don't know how
> good the optimizer is in figuring out that an array is really a scalar
> value. I suspect it is not doing a good job but I am not sure.
>
> Ideally I want to provide as much information to the compiler as
> possible but I am not sure of the mechanics of doing so. I have read
> the docs and am looking at code in TypeDictionary etc. but it would be
> more helpful to have specific answers / examples for the following:
>
>
> 1. If a value is scalar but represented as an aggregate and accessed
> using array store/load - is this bad for the optimizer?
>
> 2. For scalar local values should I used loadTemporary and storeTemporary
> ops?
>
> 3. What aliasing or shadow information do I need to provide for above?
>
> I am using local byte arrays to represent aggregates. An aggregate may
> be any C structure such as structs or unions or arrays etc. I use
> array load/store to access values in the aggregate.
>
> I don't even know how to phrase my question here but basically I want
> to be able to tell the compiler as much as possible about the
> aggregate access. From the little I understand so far:
>
> 5. Do I need separate (distinct) shadow symrefs for every load /store
> ? Can a shadow symref be reused - and if so under what conditions?
>
> 6. Does a shadow ref need to have an offset ?
>
> 7. What if the shadow ref is accessing a part of the aggregate that is
> at a runtime computed offset,
> e.g. an array index?
>
> I am currently using following shadow ref code:
>
> auto array_offset = get_array_element_address(injector, type, base, index);
> auto loadOp = TR::ILOpCode::indirectLoadOpCode(type);
> TR::SymbolReference *symRef =
> injector->symRefTab()->findOrCreateArrayShadowSymbolRef(type, base);
> TR::Node *load = TR::Node::createWithSymRef(loadOp, 1, array_offset, 0,
> symRef);
>
> I do not understand what I am doing here - but basically it seems to
> me that I may be reusing the same shadow symbol ref for disparate
> local aggregate objects as the shadow ref lookup is only based on the
> type being accessed. Do all shadow refs for a particular object type /
> or local instance of object need to be distinct?
>
> I am reading the docs and looking at the code in OMR to work all this
> out ... but sadly it isn't clear to me yet how this is supposed to be
> used. If the OMR team can provide me some detailed guidance / examples
> of each of the scenarios above that would be very much appreciated.
>
> Many thanks
>
> Regards
> Dibyendu
> _______________________________________________
> omr-dev mailing list
> omr-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/omr-dev
>
>
>
>