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

["Vijay Sundaresan" <vijaysun@xxxxxxxxxx>]

Hi,

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.

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.

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