[M3devel] importing types not described to backend

[Jay K]

I've been quite banging my head against this.
I believe basically every type referenced in a module must be
"described" to the backend, such as with declare_opaque, declare_record, etc.

Type.Compile should call t.compile on more stuff.
You need not declare everything in every imported module. Only types that are used.

There is at least one hard to solve problem here, for some level of lack of understanding at least.
Specifically if you call t.compile on all types in Type.Compile, RecordType.Compiler => Scope.InitValues
 => assertion failures about non-empty stack.

It seems Type.Compile gets called "in the middle of stuff" instead of just from CompileAll.

I'm almost stumped.
I have to check still where Type.Compile vs. Type.CompileAll are called.

 - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: RE: [M3devel] importing types not described to backend
> Date: Sat, 28 Aug 2010 09:54:54 +0000
>
>
> Interesting.
>
> TYPE Color1 = RECORD a,b,c: REAL; END;
> TYPE Color2 = RECORD a,b,c: REAL; END;
>
> Have the same id.
> If the module defining them also imports an interface with a type with the same id,
>   or I think, if its interface defines a type with same id (same thing I think,
>   no relationship at the cg level between a module and its interface),
> then the declare_records are skipped.
>
> The fix is probably something simple in Type.Compile involve the order it checks the tables in
> when deciding to call t.compile or not.
>
> Or can it just always call t.compile?
> Worst thing is that extra type information created?
> A lot of it? (all types in all imports, instead of just the used ones??)
>
>  - Jay
>
> ----------------------------------------
> > From: jay.krell at cornell.edu
> > To: m3devel at elegosoft.com
> > Subject: RE: [M3devel] importing types not described to backend
> > Date: Fri, 27 Aug 2010 18:35:00 +0000
> >
> >
> > Very wierd:
> >
> > MODULE Main;
> > IMPORT Color;
> > TYPE ColorT = RECORD a,b,c: REAL; END;
> >
> > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) =
> > BEGIN
> > END F1;
> >
> > BEGIN
> > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0});
> > END Main.
> >
> >
> > This fails. If you remove the IMPORT, it worked.
> > The declare_record of ColorT comes and goes with that change.
> > So I guess the error really is in F1.
> >
> >
> > - Jay
> >
> > ----------------------------------------
> > > From: jay.krell at cornell.edu
> > > To: m3devel at elegosoft.com
> > > Date: Fri, 27 Aug 2010 18:28:47 +0000
> > > Subject: [M3devel] importing types not described to backend
> > >
> > >
> > > This is distilled from m3-ui/anim3d/src/x-opengl/X_OpenGL_Base.m3
> > >
> > > INTERFACE Color;
> > > TYPE T = RECORD a,b,c:REAL; END;
> > > END Color.
> > >
> > >
> > > MODULE Main;
> > > IMPORT Color;
> > > TYPE ColorT = RECORD a,b,c: REAL; END;
> > >
> > >
> > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) =
> > > BEGIN
> > > END F1;
> > >
> > >
> > > <*NOWARN*> PROCEDURE F2 (a,b,c,d,e,f:INTEGER; g:Color.T) =
> > > BEGIN
> > > END F2;
> > >
> > >
> > > BEGIN
> > > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0});
> > > F2(2,3,4,5,6,7,Color.T{2.0,3.0,4.0});
> > > END Main.
> > >
> > >
> > > On SPARC64_SOLARIS there is an assertion failure in the backend:
> > > /dev2/cm3/m3-sys/m3cc/SPARC64_SOLARIS/gcc/m3cgc1 -mno-app-regs -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ Main.mc -o Main.ms
> > > ../Main.m3: In function 'Main__F1':
> > > ../Main.m3:13: internal compiler error: in function_arg_record_value, at config/sparc/sparc.c:5038
> > >
> > >
> > > I fixed it so F1 is ok.
> > > But still F2 isn't.
> > > The error is reported for F1, though that is wrong. If you comment out F2, it compiles ok.
> > >
> > >
> > > The problem as I understand is we don't tell the backend about imported types.
> > > There is nothing in the IR about them, judging from -y and a quick look at parse.c.
> > >
> > >
> > > I intend to fix this if I don't here any objections.
> > > I'm hoping it isn't too much work.
> > > I believe it will mostly/all be in m3front.
> > >
> > >
> > > My opinion of our gcc backend drops..
> > >
> > >
> > > Perhaps the time is better used on a C front end.
> > > Though in this case, I think the work is shared, the same stuff would be missing there too.
> > >
> > >
> > > Thanks,
> > > - Jay
> > >
> >
>