Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eliminate std::vector from Type #1581

Closed
lattner opened this issue Feb 18, 2007 · 6 comments
Closed

Eliminate std::vector from Type #1581

lattner opened this issue Feb 18, 2007 · 6 comments
Labels
bugzilla Issues migrated from bugzilla code-cleanup llvm:core

Comments

@lattner
Copy link
Collaborator

lattner commented Feb 18, 2007

Bugzilla Link 1209
Resolution FIXED
Resolved on Feb 22, 2010 12:53
Version trunk
OS All

Extended Description

Type::ContainedTys is a vector of PATypeHandle's. It would be much more efficient to coallocate the array
on the end of the type object. This is a little tricky due to the fact that Type has subclasses.

@llvmbot
Copy link
Member

llvmbot commented Mar 26, 2007

I would like to do this, Chris, but I'm not sure what you mean by "coallocate
the array on the end of the type object". Are you suggesting that we make
members like:

uint16_t NumContainedTys;
PATypeHandle* ContainedTys[];

in the Type class and then allocate additional space at the end of the object
for the pointers to the contained types? This would get rid of the std::vector.

If that's not what you mean, could you clarify, please?

@lattner
Copy link
Collaborator Author

lattner commented Mar 26, 2007

I would like to do the standard trick of using:

struct foo {
stuff
T array[];
}

instead of:

struct foo {
stuff
T *array; // separate allocation.
}

In this case, T is PATypeHandle. Is that what you wanted to know?

-Chris

@llvmbot
Copy link
Member

llvmbot commented Mar 27, 2007

I think we're proposing the same thing, except:

  1. Don't we need to keep the size of the array-at-the-end somewhere?
  2. I added a PATypeHolder* in the Type class so it could access it regardless of
    the subclass. The subclass would be responsible for setting it to the correct
    address (inside the instantiated object).

Does this make sense or do you have something more clever in mind?

@lattner
Copy link
Collaborator Author

lattner commented Mar 27, 2007

Yup, that sounds right!

-Chris

@llvmbot
Copy link
Member

llvmbot commented Apr 6, 2007

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
clementval pushed a commit to clementval/llvm-project that referenced this issue Apr 20, 2022

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
The case where the dummy argument is OPTIONAL was missing in the
handling of VALUE numerical and logical dummies (passBy::BaseAddressValueAttribute).
This caused segfaults while unconditionally copying actual arguments that were legally
absent at runtime.

Takes this bug as an opportunity to share the code that lowers arguments
that must be passed by BaseAddress, BaseAddressValueAttribute, BoxChar,
and CharBoxValueAttribute.
It has to deal with the exact same issues (being able to make contiguous
copies of the actual argument, potentially conditionally at runtime,
and potentially requiring a copy-back).
The VALUE case is the same as the non value case, except there is never
a copy-back and there is always a copy-in for variables. This two
differences are easily controlled by a byValue flag.

This as the benefit of implementing CHARACTER, VALUE for free that was
previously a hard TODO.
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla code-cleanup llvm:core
Projects
None yet
Development

No branches or pull requests

2 participants