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...