It sounds to me like you are proposing option 2 from my last mail. That is,
rather
than storing the IR as:
CallExpr(SymExpr(FnSymbol('sizeof')),
SymExpr(VarSymbol('c_string' w/ FLAG_TYPE_SYMBOL flag)))
at codegen time, you're proposing storing it as:
CallExpr(SymExpr(FnSymbol('sizeof')),
SymExpr(TypeSymbol('c_string')))
On the surface, this seems reasonable to me (if I've got it right). That said,
I don't get to play with the IR as much as I'd like these days, so may be
overlooking some reason that the first form is preferable.
-Brad
________________________________________
From: Michael Ferguson [[email protected]]
Sent: Wednesday, August 27, 2014 6:21 AM
To: Brad Chamberlain
Cc: [email protected]
Subject: Re: [Chapel-developers] module init functions
Hi -
>> I continue to have the position that the code generator should not need
>> to know about type symbols; something is either a Type or a Variable...
>
> That's a valid opinion, but it's still not clear to me whether you're
> proposing:
>
> * deprecating the ability to have extern functions that take type
> arguments (like sizeof())
>
> or
>
> * representing calls like 'sizeof(c_int)' in a different way within the
> IR (in which case, how are you proposing representing them?)
Well... neither. I'd propose that the Type be passed directly in as
an argument. Variables get e.g. stack allocated, which makes no sense
for a type. What I don't know if c_int could always be represented
as a Type (vs VarSymbol with FLAG_TYPE_SYMBOL) through compilation
or if some pass would lower it. I'd want arguments/variables to either be:
- VarSymbol that can be e.g. stack allocated and exists at runtime
or
- Type that can be used in e.g. sizeof
By the time we get to code generation, I don't think there's anything
relevant in the fact that c_int used to be a 'variable' in the
compiler (since type variables will be totally resolved by then).
I'd reserve VarSymbol + FLAG_TYPE_SYMBOL for cases when runtime type
information needs to be generated.
-michael
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
