On Feb 15, 2011, at 7:40 AM, Gabriel Kerneis wrote: > On Thu, Jan 20, 2011 at 10:57:22PM -0500, Elnatan Reisner wrote: >> The attached patch keeps the typedefed type in casts, rather than >> unrolling to the underlying type. > > Applied in svn r12134. > > Note that in some cases in the pattern-matching (eg. TArray), the > variable [result] in not used, and the cast is rebuilt. Since I do > not > fully understand what happens in those cases, I amended your patch to > keep previous behaviour (ie. unroll types). If you think [result] > should be used, or types shall be kept unrolled in some of these > cases, > please let me know.
I haven't thought hard about this, but it looks to me like the key in the cases where result is not used is just that the cast is not inserted, so I think you should still used the 'rolled' type---that is, the input [nt], rather than [unrollType nt]. Two of the changes you made affect error messages; I don't know what would be more understandable, but I would think reporting the typedef'ed name would be better. Also, in the TComp case where a recursive call is made to castTo, I would think that this case, too, should use the input [nt] rather than the unrolled type. But, as I said, I haven't thought very hard about this. > Thanks for the patch, My pleasure. I was inspired by my desire to have CIL's transformation to be idempotent: I would love it if a program passed through CIL twice is the same as the program passed through only once. I don't think this quite gets there (I don't remember exactly what issues remain), but it's a step. Elnatan ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ CIL-users mailing list CIL-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cil-users
