search for: fileoutputbuff

On Thu, May 17, 2012 at 3:25 PM, Nick Kledzik <kledzik at apple.com> wrote: > I now have an implementation of FileOutputBuffer (OutputBuffer was already taken).  The patch supports the functionality listed below and I've tested that it works for lld. > > To implement the FileOutputBuffer, I needed to add some more functions to llvm/Support/FileSystem.h, including: >   is_writable_file() >   is_executable_...

I now have an implementation of FileOutputBuffer (OutputBuffer was already taken). The patch supports the functionality listed below and I've tested that it works for lld. -------------- next part -------------- A non-text attachment was scrubbed... Name: FileOutputBuffer.patch Type: application/octet-stream Size: 25308 bytes Desc: not...

...d. The same is true for other llvm tools. As an example, put a breakpoint in Writer.cpp:236 ("writeBuildId()") and restart the run a few times. You will get t.tmp43a735a t.tmp4deeabb t.tmp9bacdd3 t.tmpe4115c4 t.tmpeb01fff The same would happen if there was a fatal error between the FileOutputBuffer creation and commit. I don't think that is a code path where that is possible right now, but it would be an easy thing to miss in a code review. I was hopping the OS could help us manage the temporary file so that there was no way to accidentally leave it behind. On linux there is O_TMPFILE...

On Fri, May 18, 2012 at 3:07 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > >> +  error_code ec = sys::fs::status(filePathTwine, stat); > > stat is undefined if ec isn't success. ec will be success even in the case of > file_not_found. Actually I was wrong. The Windows and UNIX implementation disagree on this point. I'm going to change it to match

On May 8, 2012, at 4:08 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On May 8, 2012, at 3:41 PM, Michael Spencer wrote: > >> On Mon, May 7, 2012 at 12:56 PM, Nick Kledzik <kledzik at apple.com> wrote: >>> For the reasons listed in my 03-May-2012 email, I am proposing a new >>> llvm/Support class for using in writing binary files: >>>

..., gold takes 27.05 seconds to link it. With the results, I'm *not* going to submit that change. There are two reasons. First, the optimization seems too system-specific, and I'm not yet sure if it's always effective even on Linux. Second, the current implementations of MemoryBuffer and FileOutputBuffer are not sendfile(2)-friendly because they close file descriptors immediately after mapping them to memory. My patch is too hacky to submit. Being said that, the results clearly show that there's room for future optimization. I think we want to revisit it when we want to do a low-level optimi...

On May 8, 2012, at 3:41 PM, Michael Spencer wrote: > On Mon, May 7, 2012 at 12:56 PM, Nick Kledzik <kledzik at apple.com> wrote: >> For the reasons listed in my 03-May-2012 email, I am proposing a new >> llvm/Support class for using in writing binary files: >> >> /// OutputBuffer - This interface provides simple way to create an in-memory >> /// buffer

...hen a call to `readBytes` spans a block boundary, it does multiple reads, allocates a contiguous buffer from a `BumpPtrAllocator` and returns a reference to that (subsequent requests for the same offset return from the cached allocation). There is also *FileBufferThinStream* which adapts an `llvm::FileOutputBuffer` so you can write to a file system object. One could easily imagine an implementation that adapts `llvm::MemoryBuffer` so that you could read and write from mmap'ed files. But all of these just allow reading and writing raw bytes. To handle reading and writing semantic data, there are two...

...proposed patch to enhance FileSystem.h to add functionality (getting and setting permission bits and mapping an unmapping files). This implementation follows the N3365 proposal regarding permission bits. This functionality is needed for my next patch which will implement llvm/include/Support/FileOutputBuffer.h which is needed by lld. -------------- next part -------------- A non-text attachment was scrubbed... Name: FileSystem.patch Type: application/octet-stream Size: 10014 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120618/828a8f3e/attachment.obj> -...

2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org>: > Changing a header file somewhere and having to spend 10 minutes waiting > for a build leads to a lot of wasted developer time. > > The real culprit here is tablegen. Can we split support and ADT into two > - the parts that tablegen depends on and the parts that it doesn't? >

Does FreeBSD have fallocate(2) or equivalent? On Mon, Oct 30, 2017 at 4:32 PM, Ed Maste <emaste at freebsd.org> wrote: > On 23 October 2017 at 18:49, Rui Ueyama via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > >> > >> BTW, posix_fallocate() might provide better portability and decrease the > >> likelihood of falling back on ftruncate(). > >

...Capacity > Casting > Chrono > circular_raw_ostream > COM.h > CommandLine.h > Compiler.h > ConvertUTF.h > CrashRecoveryContext.h > DataExtractor.h > Debug.h > Endian.h > EndianStream.h > Errc.h > Errno.h > Error.h > ErrorHandling.h > ErrorOr.h > FileOutputBuffer.h > FileSystem.h > FileUtilities.h > Format*.h > GlobPattern.h > Host.h > JamCRC.h > KnownBits.h > LineIterator.h > Locale.h > ManagedStatic.h > MathExtras.h > MD5.h > Memory.h > MemoryBuffer.h > Mutex.h > MutexGuard.h > NativeFormatting.h > O...

...Capacity > Casting > Chrono > circular_raw_ostream > COM.h > CommandLine.h > Compiler.h > ConvertUTF.h > CrashRecoveryContext.h > DataExtractor.h > Debug.h > Endian.h > EndianStream.h > Errc.h > Errno.h > Error.h > ErrorHandling.h > ErrorOr.h > FileOutputBuffer.h > FileSystem.h > FileUtilities.h > Format*.h > GlobPattern.h > Host.h > JamCRC.h > KnownBits.h > LineIterator.h > Locale.h > ManagedStatic.h > MathExtras.h > MD5.h > Memory.h > MemoryBuffer.h > Mutex.h > MutexGuard.h > NativeFormatting.h > O...

...o CMakeFiles/LLVMSupport.dir/DeltaAlgorithm.cpp.o CMakeFiles/LLVMSupport.dir/DAGDeltaAlgorithm.cpp.o CMakeFiles/LLVMSupport.dir/Dwarf.cpp.o CMakeFiles/LLVMSupport.dir/Error.cpp.o CMakeFiles/LLVMSupport.dir/ErrorHandling.cpp.o CMakeFiles/LLVMSupport.dir/FileUtilities.cpp.o CMakeFiles/LLVMSupport.dir/FileOutputBuffer.cpp.o CMakeFiles/LLVMSupport.dir/FoldingSet.cpp.o CMakeFiles/LLVMSupport.dir/FormattedStream.cpp.o CMakeFiles/LLVMSupport.dir/GraphWriter.cpp.o CMakeFiles/LLVMSupport.dir/Hashing.cpp.o CMakeFiles/LLVMSupport.dir/IntEqClasses.cpp.o CMakeFiles/LLVMSupport.dir/IntervalMap.cpp.o CMakeFiles/LLVMSuppor...

...gt; >> With the results, I'm *not* going to submit that change. There are two >> reasons. First, the optimization seems too system-specific, and I'm not yet >> sure if it's always effective even on Linux. Second, the current >> implementations of MemoryBuffer and FileOutputBuffer are not >> sendfile(2)-friendly because they close file descriptors immediately after >> mapping them to memory. My patch is too hacky to submit. >> >> Being said that, the results clearly show that there's room for future >> optimization. I think we want to revi...

...ytes` spans a block > boundary, it does multiple reads, allocates a contiguous buffer from a > `BumpPtrAllocator` and returns a reference to that (subsequent requests for > the same offset return from the cached allocation). There is also > *FileBufferThinStream* which adapts an `llvm::FileOutputBuffer` so you > can write to a file system object. One could easily imagine an > implementation that adapts `llvm::MemoryBuffer` so that you could read and > write from mmap'ed files. > > But all of these just allow reading and writing raw bytes. To handle > reading and writing...

Hi Rafael, On 07/31/2017 04:20 PM, Rafael Avila de Espindola via llvm-dev wrote: > However, do we need to start with instrumentation? The original paper > uses sampling with good results and current intel cpus can record every > branch in a program. > > I would propose starting with just an lld patch that reads the call > graph from a file. The format would be very similar to

.../ELF/Writer.cpp @@ -20,11 +20,13 @@ #include "SyntheticSections.h" #include "Target.h" #include "Threads.h" +#include "llvm/ADT/Hashing.h" #include "llvm/ADT/StringMap.h" #include "llvm/ADT/StringSwitch.h" #include "llvm/Support/FileOutputBuffer.h" #include "llvm/Support/raw_ostream.h" #include <climits> +#include <unordered_set> using namespace llvm; using namespace llvm::ELF; @@ -896,6 +898,157 @@ template <class ELFT> static void sortBySymbolsOrder() { Sec->sort([&](InputSectionBase...

.../ELF/Writer.cpp @@ -20,11 +20,13 @@ #include "SyntheticSections.h" #include "Target.h" #include "Threads.h" +#include "llvm/ADT/Hashing.h" #include "llvm/ADT/StringMap.h" #include "llvm/ADT/StringSwitch.h" #include "llvm/Support/FileOutputBuffer.h" #include "llvm/Support/raw_ostream.h" #include <climits> +#include <unordered_set> using namespace llvm; using namespace llvm::ELF; @@ -922,6 +924,157 @@ static void sortBySymbolsOrder(ArrayRef<OutputSection *> OutputSections) { Sec->sort([&...

.../ELF/Writer.cpp @@ -20,11 +20,13 @@ #include "SyntheticSections.h" #include "Target.h" #include "Threads.h" +#include "llvm/ADT/Hashing.h" #include "llvm/ADT/StringMap.h" #include "llvm/ADT/StringSwitch.h" #include "llvm/Support/FileOutputBuffer.h" #include "llvm/Support/raw_ostream.h" #include <climits> +#include <unordered_set> using namespace llvm; using namespace llvm::ELF; @@ -896,6 +898,153 @@ template <class ELFT> static void sortBySymbolsOrder() { Sec->sort([&](InputSectionBase...