mclow.lists accepted this revision.
mclow.lists added a comment.
This revision is now accepted and ready to land.
Yes, sorry.
http://reviews.llvm.org/D15539
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailma
bcraig added a comment.
@mclow.lists ping
http://reviews.llvm.org/D15539
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bcraig added a comment.
So does this latest revision get the check-mark of approval?
http://reviews.llvm.org/D15539
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mclow.lists added a comment.
> Any objections to using the original sizes, but constructing the objects at
> global scope?
I think that should work.
http://reviews.llvm.org/D15539
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lis
bcraig updated the summary for this revision.
bcraig updated this revision to Diff 47327.
http://reviews.llvm.org/D15539
Files:
test/dynamic_cast14.pass.cpp
Index: test/dynamic_cast14.pass.cpp
===
--- test/dynamic_cast14.pass.cpp
bcraig added a comment.
Any objections to using the original sizes, but constructing the objects at
global scope? That fixes the stack usage without significantly changing the
layout characteristics of the test?
http://reviews.llvm.org/D15539
___
mclow.lists added a comment.
I think you've reduced the scope of the tests significantly with this change.
If you want to make the objects smaller, that's fine - but please heed Howard's
advice in the email thread:
- Don't make them too small. (three digits is better than two)
- Keep the objec
bcraig added a comment.
@mclow.lists ping
http://reviews.llvm.org/D15539
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bcraig added a comment.
ping
http://reviews.llvm.org/D15539
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jroelofs added a comment.
FOAD: Ball's in @mclow.lists's court, not mine. I don't feel comfortable
signing off on this.
http://reviews.llvm.org/D15539
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/lis
bcraig added a comment.
ping
http://reviews.llvm.org/D15539
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bcraig added a comment.
Ping.
If desired, I could provide an alternative implementation where all the structs
are allocated at global scope with their original padding.
http://reviews.llvm.org/D15539
___
cfe-commits mailing list
cfe-commits@lists.l
bcraig added a comment.
In http://reviews.llvm.org/D15539#312336, @jroelofs wrote:
> In http://reviews.llvm.org/D15539#312332, @bcraig wrote:
>
> > In http://reviews.llvm.org/D15539#312319, @jroelofs wrote:
> >
> > > What does having them be `long double`s give over just multiplying the
> > > co
jroelofs added a comment.
In http://reviews.llvm.org/D15539#312336, @jroelofs wrote:
> In http://reviews.llvm.org/D15539#312332, @bcraig wrote:
>
> > In http://reviews.llvm.org/D15539#312319, @jroelofs wrote:
> >
> > > What does having them be `long double`s give over just multiplying the
> > >
jroelofs added a comment.
In http://reviews.llvm.org/D15539#312332, @bcraig wrote:
> In http://reviews.llvm.org/D15539#312319, @jroelofs wrote:
>
> > What does having them be `long double`s give over just multiplying the
> > counts by 16 (or however big it is on your platform)? Alignment?
> >
>
bcraig added a comment.
In http://reviews.llvm.org/D15539#312319, @jroelofs wrote:
> What does having them be `long double`s give over just multiplying the counts
> by 16 (or however big it is on your platform)? Alignment?
>
> Seems like it'd be better to start with a prime that's ~16x larger, s
jroelofs added a comment.
What does having them be `long double`s give over just multiplying the counts
by 16 (or however big it is on your platform)? Alignment?
Seems like it'd be better to start with a prime that's ~16x larger, say 211,
than to have that factor of 16 floating around everywher
bcraig updated this revision to Diff 43041.
bcraig added a comment.
Starting primes at 13, and skipping the larger twin in twin prime pairs. Using
long double instead of char for padding to help alleviate fears of multiple
structs having the same actual size.
http://reviews.llvm.org/D15539
F
That would destroy the timing information, but no one seems to be paying
attention to that anyway. I recommend just picking smaller buffer sizes. But
11 is too small. Small enough to pass on your embedded platform, but not in
the range of a typical alignof(max_align_t).
Howard
On Dec 16, 20
As an alternative, would it be acceptable to heap allocate these
objects, using the original padding numbers?
On 12/15/2015 5:11 PM, Howard Hinnant wrote:
On Dec 15, 2015, at 5:30 PM, Jonathan Roelofs wrote:
Could these large padding things be related to the fact that the test is used
as a
bcraig added a subscriber: bcraig.
bcraig added a comment.
As an alternative, would it be acceptable to heap allocate these
objects, using the original padding numbers?
http://reviews.llvm.org/D15539
___
cfe-commits mailing list
cfe-commits@lists.l
On Dec 15, 2015, at 5:30 PM, Jonathan Roelofs 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
> a
bcraig added a comment.
In http://reviews.llvm.org/D15539#311343, @jroelofs 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
jroelofs added subscribers: howard.hinnant, jroelofs.
jroelofs added a comment.
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 thi
bcraig created this revision.
bcraig added a reviewer: mclow.lists.
bcraig added a subscriber: cfe-commits.
This test has a lot of classes with large amounts of manually inserted padding
in them, presumable to prevent various optimizations. The test then creates
lots of these objects on the sta
25 matches
Mail list logo
