Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [omr-dev] Symbol refs, shadow refs and aliasing



On Wed, Jul 4, 2018 at 6:13 PM Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx> wrote:
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?

Unfortunately not as aggregates are not really fully represented in the OMR IL. JitBuilder treats them as a local array of bytes (and that was done as a first attempt for a project that needed to represent aggregates similarly to C/C++), and there's the TR::Aggregate data type that was used for similar things back when this code was closed source, but there isn't much support beyond that that lets you use them as first class data types like primitives.

How to best represent aggregates is still very much an open question, e.g. does the node represent the 'value' or address of the aggregate, how do you square that with OMR IL's need to pass values between basic blocks via memory (prior to the optimizer forming EBBs and commoning across them), how do you distinguish between passing/returning an aggregate by value v.s. passing/returning it's address, how do you copy it by value, how do you represent passing/returning across function calls, how do you represent the differing ABI constraints across platforms, how do you access its members (do you overload the indirect ops we already have, invent new ones, use direct accesses) and so on and so forth. You can probably get by some of these issues by doing the dirty work yourself and generating code specific to your combination of language/IL generator/environment, but you're in here-be-dragons territory for the most part.

Back to the top