| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
| |
|
|
|
|
|
|
|
|
|
| |
For example, don't allow empty strings to be passed to getInt.
Move asserts inside parseSpecifier. (One day we may want to pass parse
error messages to the user - from LLParser - instead of using asserts,
but keep the code simple until then. There have been an attempt to do
this. See r142288, which got reverted, and r142605.)
llvm-svn: 168991
|
| |
|
|
| |
llvm-svn: 168792
|
| |
|
|
|
|
|
|
|
| |
Accordingly, update a testcase with a broken datalayout string.
Also, we never parse negative numbers, because '-' is used as a
separator. Therefore, use unsigned as result type.
llvm-svn: 168785
|
| |
|
|
|
|
| |
Update some test cases accordingly.
llvm-svn: 168516
|
| |
|
|
| |
llvm-svn: 168042
|
| |
|
|
|
|
|
|
|
| |
This seems like redundant leftovers from r142288 - exposing
TargetData::parseSpecifier to LLParser - which got reverted. Removes
redunant td != NULL checks in parseSpecifier, and simplifies the
interface to parseSpecifier and init.
llvm-svn: 167924
|
| |
|
|
|
|
| |
they are now all correct; hopefully the buildbots will agree!).
llvm-svn: 167289
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
getIntPtrType support for multiple address spaces via a pointer type,
and also introduced a crasher bug in the constant folder reported in
PR14233.
These commits also contained several problems that should really be
addressed before they are re-committed. I have avoided reverting various
cleanups to the DataLayout APIs that are reasonable to have moving
forward in order to reduce the amount of churn, and minimize the number
of commits that were reverted. I've also manually updated merge
conflicts and manually arranged for the getIntPtrType function to stay
in DataLayout and to be defined in a plausible way after this revert.
Thanks to Duncan for working through this exact strategy with me, and
Nick Lewycky for tracking down the really annoying crasher this
triggered. (Test case to follow in its own commit.)
After discussing with Duncan extensively, and based on a note from
Micah, I'm going to continue to back out some more of the more
problematic patches in this series in order to ensure we go into the
LLVM 3.2 branch with a reasonable story here. I'll send a note to
llvmdev explaining what's going on and why.
Summary of reverted revisions:
r166634: Fix a compiler warning with an unused variable.
r166607: Add some cleanup to the DataLayout changes requested by
Chandler.
r166596: Revert "Back out r166591, not sure why this made it through
since I cancelled the command. Bleh, sorry about this!
r166591: Delete a directory that wasn't supposed to be checked in yet.
r166578: Add in support for getIntPtrType to get the pointer type based
on the address space.
llvm-svn: 167221
|
| |
|
|
|
|
|
|
|
| |
wrapper returns a vector of integers when passed a vector of pointers) by having
getIntPtrType itself return a vector of integers in this case. Outside of this
wrapper, I didn't find anywhere in the codebase that was relying on the old
behaviour for vectors of pointers, so give this a whirl through the buildbots.
llvm-svn: 166939
|
| |
|
|
|
|
| |
just call getPointerTypeSizeInBits. No functionality change.
llvm-svn: 166926
|
| |
|
|
| |
llvm-svn: 166607
|
| |
|
|
|
|
|
|
|
| |
address space.
This checkin also adds in some tests that utilize these paths and updates some of the
clients.
llvm-svn: 166578
|
| |
|
|
|
|
|
|
| |
This is important for vectors of pointers because only DataLayout,
not the underlying vector type, knows how to calculate the size
of the pointers in the vector. Fixes PR14138.
llvm-svn: 166401
|
| |
|
|
|
|
|
|
| |
to the data layout for specifying a per address space pointer size.
The next step is to update the optimizers to allow them to optimize the different address spaces with this information.
llvm-svn: 165505
|
| |
|
|
|
|
| |
projects to transition to DataLayout without loosing functionality.
llvm-svn: 165318
|
| |
|
|
| |
llvm-svn: 165270
|
| |
|
|
|
|
| |
files, this should fix the problems and the changes to rename to DataLayout will come next.
llvm-svn: 165262
|
| |
|
|
| |
llvm-svn: 165253
|
| |
|
|
|
|
| |
failure from r165249 where the wrong version of the file was submitted.
llvm-svn: 165251
|
| |
|
|
| |
llvm-svn: 165249
|
| |
|
|
| |
llvm-svn: 165244
|
|
|
llvm-svn: 165243
|
