| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D30010
llvm-svn: 295768
|
|
|
|
| |
llvm-svn: 295759
|
|
|
|
|
|
| |
There are still over 3400 files remaining with this property set, but there are tens of thousands more with the property not set. Until we decide what to do on a global scale, this at least unblocks me temporarily.
llvm-svn: 295756
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
For now I have only added support for x86_64 Linux, but other systems
can be added incrementally.
This is to be used for setting the default parallelism for ThinLTO
backends (instead of thread::hardware_concurrency which includes
hyperthreading and is too aggressive). I'll send this as a follow-on
patch, and it will fall back to hardware_concurrency when the new
getHostNumPhysicalCores returns -1 (when not supported for a given
host system).
I also added an interface to MemoryBuffer to force reading a file
as a stream - this is required for /proc/cpuinfo which is a special
file that looks like a normal file but appears to have 0 size.
The existing readers of this file in Host.cpp are reading the first
1024 or so bytes from it, because the necessary info is near the top.
But for the new functionality we need to be able to read the entire
file. I can go back and change the other readers to use the new
getFileAsStream as a follow-on patch since it seems much more robust.
Added a unittest.
Reviewers: mehdi_amini
Subscribers: beanz, mgorny, llvm-commits, modocache
Differential Revision: https://reviews.llvm.org/D25564
llvm-svn: 284138
|
|
|
|
| |
llvm-svn: 283043
|
|
|
|
|
|
|
| |
enabled): ensure that we do not invoke the sized deallocator for MemoryBuffer
subclasses that have tail-allocated data.
llvm-svn: 259735
|
|
|
|
| |
llvm-svn: 257804
|
|
|
|
|
|
|
|
|
| |
A PDB can be thought of as a very simple file system. It is
occasionally illuminating to see the contents of the underlying files.
Differential Revision: http://reviews.llvm.org/D13674
llvm-svn: 250356
|
|
|
|
|
|
|
|
| |
this is the last of them in my build of LLVM. Haven't tried Clang yet.
Found via UBSan.
llvm-svn: 243934
|
|
|
|
|
|
| |
Apparently, the style needs to be agreed upon first.
llvm-svn: 240390
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using this command:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
llvm/lib/
Thanks to Eugene Kosov for the original patch!
llvm-svn: 240137
|
|
|
|
|
|
| |
NFC.
llvm-svn: 232976
|
|
|
|
|
|
| |
Patch by Kim Grasman!
llvm-svn: 224159
|
|
|
|
|
|
| |
As a bonus we can actually check the return value.
llvm-svn: 224046
|
|
|
|
|
|
| |
This interface was added 2 years ago but users never developed.
llvm-svn: 223368
|
|
|
|
|
|
|
|
|
|
| |
mach-o supports "fat" files which are a header/table-of-contents followed by a
concatenation of mach-o files built for different architectures. Currently,
MemoryBuffer has no easy way to map a subrange (slice) of a file which lld
will need to select a mach-o slice of a fat file. The new function provides
an easy way to map a slice of a file into a MemoryBuffer. Test case included.
llvm-svn: 219260
|
|
|
|
|
|
|
| |
getOpenFileSlice gets passed the map size, so it makes no sense to say that
the size is volatile. The code will not even compute the size.
llvm-svn: 219226
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On this file we had a mix of
* Twine
* const char *
* StringRef
The two that make sense are
* const Twine & (caller convenience)
* consc char * (that is what will eventually be passed to open.
Given that sys::fs::openFileForRead takes a "const Twine &", I picked that.
llvm-svn: 219224
|
|
|
|
| |
llvm-svn: 216583
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The attached patch simplifies a few interfaces that don't need to take
ownership of a buffer.
For example, both parseAssembly and parseBitcodeFile will parse the
entire buffer before returning. There is no need to take ownership.
Using a MemoryBufferRef makes it obvious in the type signature that
there is no ownership transfer.
llvm-svn: 216488
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries
(like Archive) and we had to create dummy buffers just to handle that. It is
also a bad fit for IRObjectFile where the Module wants to own the buffer too.
Keeping this ownership would make supporting IR inside native objects
particularly painful.
This patch focuses in lib/Object. If something elsewhere used to own an Binary,
now it also owns a MemoryBuffer.
This patch introduces a few new types.
* MemoryBufferRef. This is just a pair of StringRefs for the data and name.
This is to MemoryBuffer as StringRef is to std::string.
* OwningBinary. A combination of Binary and a MemoryBuffer. This is needed
for convenience functions that take a filename and return both the
buffer and the Binary using that buffer.
The C api now uses OwningBinary to avoid any change in semantics. I will start
a new thread to see if we want to change it and how.
llvm-svn: 216002
|
|
|
|
| |
llvm-svn: 215266
|
|
|
|
| |
llvm-svn: 215248
|
|
|
|
|
|
| |
the caller don't have to initialize it.
llvm-svn: 214994
|
|
|
|
|
|
|
|
|
|
|
| |
On Cygwin, getpagesize() returns 64k(AllocationGranularity).
In r214580, the size of X86GenInstrInfo.inc became 1499136.
FIXME: We should reorganize again getPageSize() on Win32.
MapFile allocates address along AllocationGranularity but view is mapped by physical page.
llvm-svn: 214681
|
|
|
|
| |
llvm-svn: 212405
|
|
|
|
|
|
|
|
|
|
|
| |
While std::error_code itself seems to work OK in all platforms, there
are few annoying differences with regards to the std::errc enumeration.
This patch adds a simple llvm enumeration, which will hopefully avoid build
breakages in other platforms and surprises as we get more uses of
std::error_code.
llvm-svn: 210920
|
|
|
|
| |
llvm-svn: 210873
|
|
|
|
| |
llvm-svn: 210871
|
|
|
|
|
|
| |
This should make sure that most new uses use the std prefix.
llvm-svn: 210835
|
|
|
|
|
|
|
| |
This is a minimal change to remove the header. I will remove the occurrences
of "using std::error_code" in a followup patch.
llvm-svn: 210803
|
|
|
|
| |
llvm-svn: 210772
|
|
|
|
| |
llvm-svn: 210737
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The idea of this patch is to turn llvm/Support/system_error.h into a
transitional header that just brings in the erorr_code api to the llvm
namespace. I will remove it shortly afterwards.
The cases where the general idea needed some tweaking:
* std::errc is a namespace in msvc, so we cannot use "using std::errc". I could
add an #ifdef, but there were not that many uses, so I just added std:: to
them in this patch.
* Template specialization had to be moved to the std namespace in this
patch set already.
* The msvc implementation of default_error_condition doesn't seem to
provide the same transformations as we need. Not too surprising since
the standard doesn't actually say what "equivalent" means. I fixed the
problem by keeping our old mapping and using it at error_code
construction time.
Despite these shortcomings I think this is still a good thing. Some reasons:
* The different implementations of system_error might improve over time.
* It removes 925 lines of code from llvm already.
* It removes 6313 bytes from the text segment of the clang binary when
it is built with gcc and 2816 bytes when building with clang and
libstdc++.
llvm-svn: 210687
|
|
|
|
| |
llvm-svn: 210630
|
|
|
|
|
|
|
| |
There is no std::error_code::success, so this removes much of the noise
in transitioning to std::error_code.
llvm-svn: 209952
|
|
|
|
|
|
|
| |
Removes old 4096 byte workaround. This functionality has been available since
Windows XP.
llvm-svn: 209137
|
|
|
|
|
|
| |
versions are not used by lldb, lld, or clang.
llvm-svn: 209103
|
|
|
|
|
|
|
| |
Fix error handling introduced in r127426 that could result in MemoryBuffers not
having null termination.
llvm-svn: 208396
|
|
|
|
|
|
| |
These were made redundant back in r186560.
llvm-svn: 208395
|
|
|
|
|
|
| |
This can happen in practice with the user changing files and we can recover from it.
llvm-svn: 208143
|
|
|
|
|
|
| |
about the use case for the new parameter.
llvm-svn: 208026
|
|
|
|
|
|
|
|
| |
make sure to zero-initialize the rest
of the buffer if we unexpectedly reach end-of-file while reading.
llvm-svn: 208021
|
|
|
|
|
|
|
|
| |
'IsVolatile' for the open file functions.
This provides a hint that the file may be changing often so mmap is avoided.
llvm-svn: 208007
|
|
|
|
| |
llvm-svn: 205697
|
|
|
|
| |
llvm-svn: 203442
|
|
|
|
|
|
|
|
| |
This will allow external callers of these functions to switch over time
rather than forcing a breaking change all a once. These particular
functions were determined by building clang/lld/lldb.
llvm-svn: 202959
|
|
|
|
| |
llvm-svn: 202621
|
|
|
|
|
|
|
| |
This was manifesting as an LLVM_ASSUME_ALIGNED() failure in an ELF debug
info test when building LLVM with clang in the Microsoft C++ ABI.
llvm-svn: 197401
|
|
|
|
| |
llvm-svn: 193429
|