[llvm-commits] [cfe-commits] TableGen backend API refactoring review request

Sean Silva silvas at purdue.edu
Wed Jun 20 23:23:29 PDT 2012


Wow that got incredibly mangled somehow. it was meant to say:

"Thank you Jakob for patiently walking me through my first non-trivial
patch set! I'll see what I can do to ensure deterministic iteration order."

I'm still looking for a way to ensure deterministic iteration order without
making a mess of the code, such as just blindly adding a special comparator
to each of containers keyed on pointers; that would just make the code more
muddled (even in cases where the container isn't being iterated over).
There are also a couple hash tables that are keyed on Record*'s, which I
think can be changed but I'm not familiar enough with the hash traits that
they use. Any ideas for a good way to migrate to stable iteration
interfaces? Thankfully, each Record has a field `unsigned ID;` which
uniquely identifies it, so redirecting any hash/compare to that should be
safe.

--Sean Silva

On Tue, Jun 12, 2012 at 11:38 PM, Sean Silva <silvas at purdue.edu> wrote:

> Thank you Jakob for patiently ill see what I can do to ensure
> deterministic iteration order. I also havewalking me through my first
> non-trivial patch set!
>
>
> On Tue, Jun 12, 2012 at 10:17 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:
>
>>
>> On Jun 12, 2012, at 7:55 PM, Sean Silva wrote:
>>
>> > Here is a new patch updating the Clang API. It is just the minimal
>> changes to move over to the new API. The .inc files are bit-identical. For
>> now, I'll postpone 2 and 3 for a more general TableGen "cleanup" patch-set
>> at some unspecified time in the future unless you strongly feel otherwise.
>> >
>> > After this patch, you should be able to apply 3-llvm.patch from the
>> previous email and fully remove the old API.
>>
>> Committed r158388 + r158389.
>>
>> > I will see what I can do to ensure deterministic iteration order. I
>> also have some major TableGen docs updates in the works.
>>
>> Thanks!
>>
>> /jakob
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120620/0854268f/attachment.html>


More information about the llvm-commits mailing list