Hi -
Sounds like an interesting idea, and I'm generally for transformations
that simplify the generated code.
The thing I would like to add here is that I found it very confusing
(but am used to it now) that Class within the compiler means
- reference
- record
- class
- tuple
I don't philosophically disagree with 'things with fields' being
grouped into one AST element, but that AST element should be
called "Aggregate" or "Container" or something, not Class...
And along the same lines, I don't think that reference belongs
in the "Aggregate" group, since it only ever holds one element.
-michael
On 01/14/2014 07:57 PM, Brad Chamberlain wrote:
>
> Hi Chapel Developers --
>
> Here's a second opportunity for comment. A few of us have been frustrated
> for awhile about the way references are represented in the Chapel
> compiler, both in terms of making the IR more complex and making the code
> harder to reason about.
>
> In particular, for code like this:
>
> proc foo(ref x: int) { ... }
>
> var a = 1;
> foo(a);
>
> fairly early in compilation (function resolution-ish), the IR is modified
> to more-or-less represent:
>
> proc foo(ref x: ref(int)) { ... }
>
> var a = 1;
> var ref_tmp = &a;
> foo(ref_tmp);
>
> It seems regrettable to introduce these explicit reference types and their
> corresponding temps so early in the compilation process. An extreme
> argument against this might be "What if we were code generating to a
> back-end language that had different argument-passing semantics than C,
> where arguments are passed by ref by default and therefore such rewriting
> isn't necessary and may even represent a step backwards?" A simpler
> argument might just be "Is there any value in making the IR this different
> from Chapel so early (rather than closer to codegen, and dependent on
> targeting C or a C-like back-end, say)?"
>
> I've asked Kyle and Vass to explore whether we can put off transformations
> like this until a later pass in the compiler, but wanted to do a quick
> check to see if anyone had strong objections or gotchas in mind before
> they set off.
>
> Thanks,
> -Brad
>
> [For context, one motivation for this effort is to optimize such ref_tmps
> out of inlined procedures that take ref arguments. E.g., if the body of
> foo() above was:
>
> x = 0;
>
> I'd like the IR and generated code to say:
>
> a = 0;
>
> rather than:
>
> ref_tmp = &a;
> *_ref_tmp = 0;
>
> It's been argued that propagation optimizations could squash the _ref_tmp
> out of this to generate the simpler code, and I don't disagree, but my
> feeling is "Why inesrt a pointless temp in the first place?" Today the
> answer is "because the argument expects a ref(int) type and so the actual
> must match the formal." But if we were to put off the introduction of
> ref(int) types until a later pass, we could avoid the temp altogether.]
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Chapel-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/chapel-developers
>
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
