[M3devel] better type information in gcc backend

Jay K jay.krell at cornell.edu
Sun Aug 22 12:11:08 CEST 2010


This is getting interesting.

I have a small local change so that local structs have type information -- as to what fields they contain.

As a result, you can see like:

0x001d65b7 in RTType__Expand (M3_DaARCY_m=0x0) at ../src/runtime/common/RTType.m3:719
(gdb) info locals
M3_BQo8Jp_new = {
  Bd56fi_0_32_name = 0, 
  D0ztjH_32_32_is_equal = 0, 
  DXHNAh_64_32_rehash = 0, 
  Cwb5VA_96_32_initial_size = 0, 
  Cwb5VA_128_32_full = 0, 
  Cwb5VA_160_32_cnt = 0, 
  Cwb5VA_192_32_max = 0, 
  AcxOUs_224_32_mask = 0, 
  AJWxb1_256_32_map = 0
}

which is a great improvement. It used to only show you the address of the locals.

*However*, first when I put the change in, gcc would hit infinite recursions, something related to bitfields.
So I *again* disabled our wierdo bitfield stuff. That hack is a continuing thorn in my side.
  Yes it does generate better code, at least when not optimizing. We'd surely be better
  to get all the type information correct though and use member references. I realize that
  the frontend "lowers" things generally further than that, it expects a lower level backend
  than the gcc tree representation is really designed for.
Anyway..
Then it compiles.
But the result crashes. Using -O3.

And info locals actually prints the locals three times each.

More to do here..

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100822/e1148b57/attachment-0001.html>


More information about the M3devel mailing list