On Dec 15, 2015, at 5:30 PM, Jonathan Roelofs <jonat...@codesourcery.com> wrote: > > > Could these large padding things be related to the fact that the test is used > as a performance check for the implementation? That being said, I have no > idea who is paying attention to the numbers that come out of this test (if > anyone even is?). Maybe @howard.hinnant knows something about it?
It’s been a few years since I wrote this code, but my best recollection is that the large buffers indicate my concern of getting the correct answer accidentally as the dynamic_cast code will add/subtract offsets to pointers. The implementation is wicked hard to get right, and so the tests are extra paranoid. As I wrote this I only had to worry about OS X / iOS. If you need to reduce these numbers for other platforms, I think that would be fine. However I would not reduce them to double digits. I would keep them as large as you can reasonably get away with. There may have also been effort to make sure that the numbers involved were not even close to multiples of one another, or add up to each other, etc, I don’t remember for sure. The main concern is that the offset arithmetic implemented under __dynamic_cast does not accidentally get the right answer. And I suspect alignment is also factored in to the offset computation (I don’t recall for sure), and so one can not depend entirely on small primes (which may be rounded to alignment). Handy link: http://mentorembedded.github.io/cxx-abi/abi.html#dynamic_cast-algorithm Normally I don’t write a lot of comments in code. Code should be self explanatory. The sheer volume of comments in private_typeinfo.cpp should serve as a signal that this code is very tricky. So I recommend keeping the tests as paranoid as possible. Howard _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
