search for: r121659

Displaying 4 results from an estimated 4 matches for "r121659".

2010 Dec 13
0
[LLVMdev] tblgen internals
...ds in Record > reference the previously global RecordKeeper instance, I added another RecordKeeper > reference to Record, along with such a typed argument to Record's constructor, and a > corresponding factory method to RecordKeeper. This looks like great progress to me, applied in r121659. That said, it is suboptimal for Record to have to have a RecordKeeper& in it. I haven't looked at the code in a long time, is it feasible to detangle that out of record, or is it not worth it? Another random question: why is createRecord better than using "new Record"? If cre...
2010 Dec 12
2
[LLVMdev] tblgen internals
Hey Chris, The following patch removes all global references to a RecordKeeper instance for the tblgen utility. This effort was motivated by the FIXME remark, in TableGen.cpp. Although a few files were touched, the main change was to Record.h. The patch takes the simple approach of adding a RecordKeeper reference to TGParser, and any needed emitter helper classes. In addition, since some of
2010 Dec 13
4
[LLVMdev] tblgen internals
...ner wrote: > > On Dec 12, 2010, at 10:54 AM, Garrison Venn wrote: > >> >> Hey Chris, >> >> The following patch removes all global references to a RecordKeeper instance for the tblgen >> utility. > > This looks like great progress to me, applied in r121659. > > That said, it is suboptimal for Record to have to have a RecordKeeper& in it. I haven't looked at the code in a long time, is it feasible to detangle that out of record, or is it not worth it? I'll see if I can come up with another approach. This internal reference was mot...
2010 Dec 13
0
[LLVMdev] tblgen internals
..., 2010, at 10:54 AM, Garrison Venn wrote: >> >>> >>> Hey Chris, >>> >>> The following patch removes all global references to a RecordKeeper instance for the tblgen >>> utility. >> >> This looks like great progress to me, applied in r121659. >> >> That said, it is suboptimal for Record to have to have a RecordKeeper& in it. I haven't looked at the code in a long time, is it feasible to detangle that out of record, or is it not worth it? > > I'll see if I can come up with another approach. This internal...