Summary:
This merges VFPtrInfo and VBTableInfo into VPtrInfo, since they hold
almost the same information. With that change, the vbtable mangling
code can easily be applied to vftable data and we magically get the
correct, unambiguous vftable names.
Fixes PR17748.
Reviewers: timurrrr, majnemer
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2893
llvm-svn: 202425
This cleans up some constructors that would not be safe once FileEntry
owns the storage for its name. These were already suspect, since they
wouldn't work if the FileEntry had an open file descriptor. The only
user for these constructors was in UniqueFileContainer, which wasn't a
very useful abstraction anyway. So it and UniqueDirContainer have been
replaced with std::map<UniqueID, *>.
This change should not affect anything outside the FileManager.
llvm-svn: 202420
In llvm the only semantic difference between internal and private is that llvm
tries to hide private globals my mangling them with a private prefix. Since
the globals changed by this patch already had the magic don't mangle marker,
there should be no change in the generated assembly.
A followup patch should then be able to drop the \01L and \01l prefixes and let
llvm mangle as appropriate.
llvm-svn: 202419
Some MC components like Target Streamers or Assembly Parsers
may need to access the relocation model in order to expand
some directives and/or assembly macros.
llvm-svn: 202418
scan the register file for sub- and super-registers.
No functionality change intended.
(Tests are updated because the comments in the assembler output are
different.)
llvm-svn: 202416
If a function returns a large struct by value return the first 4 words
in registers and the rest on the stack in a location reserved by the
caller. This is needed to support the xC language which supports
functions returning an arbitrary number of return values. This is
r202397 reapplied with a fix to avoid an uninitialized read of a member.
llvm-svn: 202414
clang_Type_getTemplateArgument
Note that these functions don't handle variadic templates -- see tests.
Patch by Matthieu Nottale and Philippe Daouadi.
llvm-svn: 202406
Summary:
If a function returns a large struct by value return the first 4 words
in registers and the rest on the stack in a location reserved by the
caller. This is needed to support the xC language which supports
functions returning an arbitrary number of return values.
Reviewers: robertlytton
Reviewed By: robertlytton
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2889
llvm-svn: 202397
Summary:
If the src, dst and size of a memcpy are known to be 4 byte aligned we
can call __memcpy_4() instead of memcpy().
Reviewers: robertlytton
Reviewed By: robertlytton
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2871
llvm-svn: 202395
toolchain of LLVM. These are already being enforced by the build system
and have been discussed quite a few times on the lists, but
documentation is important. =]
Also, garbage collect the majority of the information about broken host
GCC toolchains. These aren't really relevant any more as they're all
older than the minimum requirement. I've left a few notes about
compilers one step older than the current requirement as these compilers
are at least conceivable to use, and it's better to preserve this kind
of hard-won institutional knowledge.
The next step will be some specific docs on how to set up a sufficiently
modern host toolchain if your system doesn't come with one. But that'll
be tomorrow. =]
llvm-svn: 202375
bits of software and to use a modern GCC version.
The Subversion bit was weird anyways -- it has nothing to do with
compiling LLVM. Also, there are many other ways to get at the trunk
source (git, git-svn, etc).
The TeXinfo thing... I have no idea about. But you can get a working
LLVM w/o it pretty easily. If man pages or something are missing, that
hardly seems like a problem. If folks really want this back, let me
know, but it seems mostly like a distraction.
I'd still like to separate this into:
- Required software to compile.
- Optional software to compile.
- Required software for certain *contributor* activities (like
regenerating configure scripts).
Also we need to mention that there are multiple options for build
systems, and the differences.
Also we should mention Windows.
Also probably other stuff I'm forgetting.
I'm wondering if this whole thing needs to be shot in the head and we
should just start a new, simpler getting started that doesn't have so
many years of accumulated stuff that is no longer relevant.
llvm-svn: 202373
getting started guide.
Some highlights:
- I heard there was this Clang compiler that you could use for your
host compiler. Not sure though.
- We no longer have a GCC frontend with weird build restrictions.
- Windows is doing a bit better than partially supported.
- We nuked everything to do with itanium.
- SPUs? Really?
- Xcode 2.5 and gcc 4.0.1 are really not a concern -- they don't work.
- OMG, we actually tried building LLVM on Alpha? Really?
- PowerPC works pretty well these days.
There is still a lot of stuff here I'm pretty dubious about, but I nuked
most of what was actively misleading, out of date, or patently wrong.
Some of it (mingw stuff especially) isn't really lacking, its just that
the comments here were actively wrong. Hopefully folks that know those
platforms can add back correct / modern information.
llvm-svn: 202370
Summary:
Fixes an issue where a test attempts to use -mcpu=x86-64 on non-X86-64 targets.
This triggers an assertion in the MIPS backend since it doesn't know what ABI to
use by default for unrecognized processors.
CC: llvm-commits, rafael
Differential Revision: http://llvm-reviews.chandlerc.com/D2877
llvm-svn: 202369
Jim Ingham