parameter of CreateIntCast then they get an error from the compiler
(or from the linker with a non-gcc compiler). Another possibility
is to flip the order of the DestTy and isSigned parameters, since you
should then get a compiler warning if you try to use a char* for a
Type*.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@88913 91177308-0d34-0410-b5e6-96231b3b80d8
This patch forbids implicit conversion of DenseMap::const_iterator to
DenseMap::iterator which was possible because DenseMapIterator inherited
(publicly) from DenseMapConstIterator. Conversion the other way around is now
allowed as one may expect.
The template DenseMapConstIterator is removed and the template parameter
IsConst which specifies whether the iterator is constant is added to
DenseMapIterator.
Actually IsConst parameter is not necessary since the constness can be
determined from KeyT but this is not relevant to the fix and can be addressed
later.
Patch by Victor Zverovich!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86636 91177308-0d34-0410-b5e6-96231b3b80d8
This makes both logical sense (see below) and increases the
number of functions marked readnone/readonly by about 1-2%
in practice. The number of functions marked nocapture goes
up by about 5-10%. The reason it makes sense is shown by
the following example: if you run -functionattrs -inline on
it, then no attributes are assigned. But if you instead run
-inline -functionattrs then @f is marked readnone because the
simplifications produced by the inliner eliminate the store.
@x = external global i32
define void @w(i1 %b) {
br i1 %b, label %write, label %return
write:
store i32 1, i32 *@x
br label %return
return:
ret void
}
define void @f() {
call void @w(i1 0)
ret void
}
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85893 91177308-0d34-0410-b5e6-96231b3b80d8
1. we'd run simplifycfg at the very start, even though
the per function passes have already cleaned this up.
2. In the main per-function pipeline that is interlaced with inlining
etc, we would do instcombine, jump threading, simplifycfg *before*
doing SROA. SROA is much more likely to expose opportunities for
these passes than they are for SROA, so move SRoA up earlier.
also add some comments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85742 91177308-0d34-0410-b5e6-96231b3b80d8
GlobalOpt already deletes trivially dead functions/globals,
so GlobalDCE only adds values for cycles of dead things.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85731 91177308-0d34-0410-b5e6-96231b3b80d8
ipconstprop and doesn't take much time. Just run it in its place.
This adds a testcase for it, which I plan to expand to cover other
"integration" cases, where we expect the optimizer to be able to
eliminate various things. Due to phase order issues we've regressed
in a number of areas and integration tests are the only way I see to
prevent this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85729 91177308-0d34-0410-b5e6-96231b3b80d8
stuff) to programmatically control the current debug flavor. While
I'm at it, doxygenate Debug.h and clean it up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85395 91177308-0d34-0410-b5e6-96231b3b80d8
Remove LowerAllocations pass.
Update some more passes to treate free calls just like they were treating FreeInst.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85176 91177308-0d34-0410-b5e6-96231b3b80d8
Update all analysis passes and transforms to treat free calls just like FreeInst.
Remove RaiseAllocations and all its tests since FreeInst no longer needs to be raised.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84987 91177308-0d34-0410-b5e6-96231b3b80d8
even when keys get RAUWed and deleted during its lifetime. By default the keys
act like WeakVHs, but users can pass a third template parameter to configure
how updates work and whether to do anything beyond updating the map on each
action.
It's also possible to automatically acquire a lock around ValueMap updates
triggered by RAUWs and deletes, to support the ExecutionEngine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84890 91177308-0d34-0410-b5e6-96231b3b80d8
s/validName/isValidName/g
s/with an Instruction/to an Instruction/g
s/RegisterMDKind/registerMDKind/g
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84689 91177308-0d34-0410-b5e6-96231b3b80d8
The JITResolver maps Functions to their canonical stubs and all callsites for
lazily-compiled functions to their target Functions. To make Function
destruction work, I'm going to need to remove all callsites on destruction, so
this patch also adds the reverse mapping for that.
There was an incorrect assumption in here that the only stub for a function
would be the one caused by needing to lazily compile it, while x86-64 far calls
and dlsym-stubs could also cause such stubs, but I didn't look for a test case
that the assumption broke.
This also adds DenseMapInfo<AssertingVH> so I can use DenseMaps instead of
std::maps.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84522 91177308-0d34-0410-b5e6-96231b3b80d8
a Value* to a WeakVH was constructing a temporary WeakVH
(due to the implicit assignment operator). This avoids
that cost.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83704 91177308-0d34-0410-b5e6-96231b3b80d8
buffer", while we work out a solution.
Dan convinced me that making debugging annoying for him is worse than 10x being
slower for me. :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82553 91177308-0d34-0410-b5e6-96231b3b80d8
This is designed for tracking a value even when it might move (like WeakVH), but it is an error to delete the referenced value (unlike WeakVH0. TrackingVH is templated like AssertingVH on the tracked Value subclass, it is an error to RAUW a tracked value to an incompatible type.
For implementation reasons the latter error is only diagnosed on accesses to a mis-RAUWed TrackingVH, because we don't want a virtual interface in a templated class.
The former error is also only diagnosed on access, so that clients are allowed to delete a tracked value, as long as they don't use it. This makes it easier for the client to reason about destruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82506 91177308-0d34-0410-b5e6-96231b3b80d8
is.
- The problem is that formatted_ostream forces its underlying buffer to be
unbuffered, so if some client happens to wrap a formatted_ostream around
something, but still use the underlying stream, then we can end up writing on
a fully unbuffered output (which was never intended to be unbuffered).
- This makes clang (and presumably llvm-gcc) -emit-llvm -S a mere 10x faster.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82434 91177308-0d34-0410-b5e6-96231b3b80d8
stringref because they may not be nul terminated. For options like -Lfoo
this now avoids a O(n) temporary std::strings where N is the length of
the string after -L.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82345 91177308-0d34-0410-b5e6-96231b3b80d8
a massive number of temporary strings created when parsing a command line.
More still left to eliminate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82318 91177308-0d34-0410-b5e6-96231b3b80d8
this is run after the 'standard function passes', SRoA was
recently run. This saves a domfrontier construction. Thanks
to Eli for noticing this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82291 91177308-0d34-0410-b5e6-96231b3b80d8
working. To support this, add an is_displayed() function to raw_ostream,
and generalize Process::StandardOutIsDisplayed and friends in order to
support it.
Also, call RemoveFileOnSignal before creating a file instead of after, so
that the file isn't left behind if the program is interrupted between when
the file is created and RemoveFileOnSignal is called.
While here, add a -S to llvm-extract and port it to IRReader so that it
supports assembly input.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81568 91177308-0d34-0410-b5e6-96231b3b80d8
(uniqued if unnamed) global variable name with the prefix that
it is supposed to get. It doesn't do "mangling" in the sense of
adding quotes and hacking on bad characters.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81505 91177308-0d34-0410-b5e6-96231b3b80d8
all disassemblers.
Modified the MemoryObject to support 64-bit address
spaces, regardless of the LLVM process's address
width.
Modified the Target class to allow extraction of a
MCDisassembler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81392 91177308-0d34-0410-b5e6-96231b3b80d8
TypeBuilder was using a local static variable to cache its result. This made it
ignore changes in its LLVMContext argument and always return a type constructed
from the argument to the first call.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81316 91177308-0d34-0410-b5e6-96231b3b80d8
of requiring a name be passed in. This makes it use "<stdin>"
instead of "-" and makes it more consistent with the Bitcode reader.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81256 91177308-0d34-0410-b5e6-96231b3b80d8
and exact flags. Because ConstantExprs are uniqued, creating an
expression with this flag causes all expressions with the same operands
to have the same flag, which may not be safe. Add, sub, mul, and sdiv
ConstantExprs are usually folded anyway, so the main interesting flag
here is inbounds, and the constant folder already knows how to set the
inbounds flag automatically in most cases, so there isn't an urgent need
for the API support.
This can be reconsidered in the future, but for now just removing these
API bits eliminates a source of potential trouble with little downside.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80959 91177308-0d34-0410-b5e6-96231b3b80d8
This is conventional command-line tool behavior. -f now just means
"enable binary output on terminals".
Add a -f option to llvm-extract and llvm-link, for consistency.
Remove F_Force from raw_fd_ostream and enable overwriting and
truncating by default. Introduce an F_Excl flag to permit users to
enable a failure when the file already exists. This flag is
currently unused.
Update Makefiles and documentation accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79990 91177308-0d34-0410-b5e6-96231b3b80d8
This change speeds up llvm-gcc by more then 6% at "-O0 -g" (measured by compiling InstructionCombining.cpp!)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79977 91177308-0d34-0410-b5e6-96231b3b80d8
means that raw_ostream no longer has to #include <iosfwd>. Nothing in llvm
should use raw_os_ostream.h, but llvm-gcc and some unit tests do.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79886 91177308-0d34-0410-b5e6-96231b3b80d8
member out of line. ftostr is not particularly speedy,
so that method is presumably not perf sensitive.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79885 91177308-0d34-0410-b5e6-96231b3b80d8
forcing them down into various .cpp files.
This change also:
1. Renames TimeValue::toString() and Path::toString() to ::str()
for similarity with the STL.
2. Removes all stream insertion support for sys::Path, forcing
clients to call .str().
3. Removes a use of Config/alloca.h from bugpoint, using smallvector
instead.
4. Weans llvm-db off <iostream>
sys::Path really needs to be gutted, but I don't have the desire to
do it at this point.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79869 91177308-0d34-0410-b5e6-96231b3b80d8
change the raw_ostream one to take the raw_ostream byref instead
of byptr. Prune #includes, eliminate a use of Streams.h
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79863 91177308-0d34-0410-b5e6-96231b3b80d8
- This also shortens the Format.h implementation, and uses the print buffer
fully (it was wasting a character).
- This manifested as llvm-test failures, because one side effect was that
raw_ostream would write garbage '\x00' values into the output stream if it
happened that the string was at the end of the buffer. This meant that grep
would report 'Binary file matches', which meant the silly pattern matching
llvm-test eventually does would fail. Cute. :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79862 91177308-0d34-0410-b5e6-96231b3b80d8
instead of as two bools. Use this to add a F_Append flag
which has the obvious behavior.
Other unrelated changes conflated into this patch:
1. REmove EH stuff from llvm-dis and llvm-as, the try blocks
are dead.
2. Simplify the filename inference code in llvm-as/llvm-dis,
because raw_fd_ostream does the right thing with '-'.
3. Switch machine verifier to use raw_ostream instead of ostream
(Which is the thing that needed append in the first place).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79807 91177308-0d34-0410-b5e6-96231b3b80d8
bytes. libgcc doesn't seem to mind, but if you pass this DWARF to GDB, it
doesn't like it.
Also make the JIT memory manager to initialize it's memory to garbage in debug
mode, so that it's easier to find bugs like these in the future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79674 91177308-0d34-0410-b5e6-96231b3b80d8
right.
- This class turns out to be much more convenient to use if we do this; clients
can make sure the buffer is always big enough if they care (since our current
idiom tends to be to use a SmallString<256> for the input to this we should
generally be avoiding an unnecessary malloc).
Also, add a convenience raw_svector_ostream::str method which flushes the buffer
and returns a StringRef for the vector contents.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79446 91177308-0d34-0410-b5e6-96231b3b80d8
- This avoids unnecessary malloc/free overhead in the common case, and
unnecessary copying from the ostream buffer into the output vector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79434 91177308-0d34-0410-b5e6-96231b3b80d8
when trying to run opt in parallel. This lets parallel opt crunch 403.gcc in about a third
of the time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79387 91177308-0d34-0410-b5e6-96231b3b80d8
- Kill off begin(), end(), and iterator. It isn't clear what these
mean. Instead provide getBufferStart(), which can be used with
GetNumBytesInBuffer to the same effect.
- Update ComputeColumn to take arguments for the buffer to scan, this
simplifies the implementation of write_impl substantially.
- This should also fix possible problems with the scanning pointer pointing
outside of the current raw_ostream buffer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79379 91177308-0d34-0410-b5e6-96231b3b80d8
In order for the changes in r78424 to work properly, cast_retty<X,Y> should return an object instead of a reference, and it's not clear that this approach has real advantages.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79023 91177308-0d34-0410-b5e6-96231b3b80d8
unbuffered. std::ostream does its own buffering, and std::string and
SmallVector both have allocation strategies intended to handle frequent
appending.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78924 91177308-0d34-0410-b5e6-96231b3b80d8
needs of the underlying output mechanism. raw_fd_ostream now uses
st_blksize from fstat to determine a buffer size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78923 91177308-0d34-0410-b5e6-96231b3b80d8
This definitely slows down asm output so put it under an -asm-exuberant
flag.
This information is useful when doing static analysis of performance
issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78567 91177308-0d34-0410-b5e6-96231b3b80d8
The use case is if you have a wrapper class:
class Base {
void *Ptr;
public:
Base() : Ptr(0) { }
operator bool() const { return Ptr; }
.....
}
and sub-wrappers that have exactly the same size:
class Sub : public Base {
public:
....
static bool classof(const Base*);
}
and in the code you would do:
void f(Base b) {
Sub sub = dyn_cast<Sub>(b);
if (sub) {
....
}
}
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78424 91177308-0d34-0410-b5e6-96231b3b80d8
http://llvm.org/viewvc/llvm-project?view=rev&revision=78127, I'm changing the
ExecutionEngine's global mappings to hold AssertingVH<const GlobalValue>. That
way, if unregistering a mapping fails to actually unregister it, we'll get an
assert. Running the jit nightly tests didn't uncover any actual instances of
the problem.
This also uncovered the fact that AssertingVH<const X> didn't work, so I fixed
that too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78400 91177308-0d34-0410-b5e6-96231b3b80d8
just argv[0]. And remove the code for searching the current
working directory and for searching PATH; the point of FindExecutable
is not to find whatever version of the executable can be found by
searching around, but to find an executable that accompanies the
current executable.
Update the tools to use sys::Program::FindProgramByName when they
want PATH searching.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78240 91177308-0d34-0410-b5e6-96231b3b80d8
values the same way it treats null pointers. This is needed to allow
CallbackVH to be used as a key in a DenseMap.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77695 91177308-0d34-0410-b5e6-96231b3b80d8
it conforms to the assertion added in r77245. This fixes a failure
in qa_override.c in clang's testsuite.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77255 91177308-0d34-0410-b5e6-96231b3b80d8
I'm returning the number of bytes actually copied so that the client has some
warning when it reads past the end of the buffer.
I'm keeping the distinction between getByte() and getBytes() for now for
subclasses that use functions like ptrace() on Linux and only have a restricted
interface. This makes their implementation easier, and subclasses can always
write a one-line implementation of readByte() that uses their custom
readBytes().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77225 91177308-0d34-0410-b5e6-96231b3b80d8
Necessary for cases in which the memory is in another process, in a
file, or on a remote machine.
The primary use for this is the llvm-mc disassemblers, so that they
can be targeted at arbitrary objects, not just in-process memory.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77023 91177308-0d34-0410-b5e6-96231b3b80d8
- Yay for '-'s and simplifications!
- I kept StringMap::GetOrCreateValue for compatibility purposes, this can
eventually go away. Likewise the StringMapEntry Create functions still follow
the old style.
- NIFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76888 91177308-0d34-0410-b5e6-96231b3b80d8
malloc, so there should be no functional changes to other code.
These changes are necessary since I have plans to use this allocator in the JIT
memory manager, and it needs a special allocator.
I also added some tests which helped me pinpoint some bugs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76825 91177308-0d34-0410-b5e6-96231b3b80d8
printers to do neat and wonderful things when printing debug
information. The ideas is to allow passes to configer printers to emit
pass-specific information when dumping IR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76602 91177308-0d34-0410-b5e6-96231b3b80d8
"private" symbols which the assember shouldn't strip, but which the linker may
remove after evaluation. This is mostly useful for Objective-C metadata.
This is plumbing, so we don't have a use of it yet. More to come, etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76385 91177308-0d34-0410-b5e6-96231b3b80d8
all values belonging to the intersection will belong to the resulting range.
The former was inconsistent about that point (either way is fine, just pick
one.) This is part of PR4545.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76289 91177308-0d34-0410-b5e6-96231b3b80d8
call to the MachineCodeEmitter interface and made copying the start
line of a function not conditional on whether we're emitting Dwarf
debug information. I'll propagate the processDebugLoc() calls to the
non-X86 targets in a followup patch.
In the long run, it'll probably be better to gather this information
through the DwarfWriter, but the DwarfWriter currently depends on the
AsmPrinter and TargetAsmInfo, and fixing that would be out of the way
for this patch.
There's a bug in OProfile 0.9.4 that makes it ignore line numbers for
addresses above 4G, and a patch fixing it at
http://thread.gmane.org/gmane.linux.oprofile/7634
Sample output:
$ sudo opcontrol --reset; sudo opcontrol --start-daemon; sudo opcontrol --start; `pwd`/Debug/bin/lli fib.bc; sudo opcontrol --stop
Signalling daemon... done
Profiler running.
fib(40) == 165580141
Stopping profiling.
$ opreport -g -d -l `pwd`/Debug/bin/lli|head -60
Overflow stats not available
CPU: Core 2, speed 1998 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000
vma samples % linenr info image name symbol name
00007f67a30370b0 25489 61.2554 fib.c:24 10946.jo fib_left
00007f67a30370b0 1634 6.4106 fib.c:24
00007f67a30370b1 83 0.3256 fib.c:24
00007f67a30370b9 1997 7.8348 fib.c:24
00007f67a30370c6 2080 8.1604 fib.c:27
00007f67a30370c8 988 3.8762 fib.c:27
00007f67a30370cd 1315 5.1591 fib.c:27
00007f67a30370cf 251 0.9847 fib.c:27
00007f67a30370d3 1191 4.6726 fib.c:27
00007f67a30370d6 975 3.8252 fib.c:27
00007f67a30370db 1010 3.9625 fib.c:27
00007f67a30370dd 242 0.9494 fib.c:27
00007f67a30370e1 2782 10.9145 fib.c:28
00007f67a30370e5 3768 14.7828 fib.c:28
00007f67a30370eb 615 2.4128 (no location information)
00007f67a30370f3 6558 25.7287 (no location information)
00007f67a3037100 15603 37.4973 fib.c:29 10946.jo fib_right
00007f67a3037100 1646 10.5493 fib.c:29
00007f67a3037101 45 0.2884 fib.c:29
00007f67a3037109 2372 15.2022 fib.c:29
00007f67a3037116 2234 14.3178 fib.c:32
00007f67a3037118 612 3.9223 fib.c:32
00007f67a303711d 622 3.9864 fib.c:32
00007f67a303711f 385 2.4675 fib.c:32
00007f67a3037123 404 2.5892 fib.c:32
00007f67a3037126 634 4.0633 fib.c:32
00007f67a303712b 870 5.5759 fib.c:32
00007f67a303712d 62 0.3974 fib.c:32
00007f67a3037131 1848 11.8439 fib.c:33
00007f67a3037135 2840 18.2016 fib.c:33
00007f67a303713a 1 0.0064 fib.c:33
00007f67a303713b 1023 6.5564 (no location information)
00007f67a3037143 5 0.0320 (no location information)
000000000080c1e4 15 0.0360 MachineOperand.h:150 lli llvm::MachineOperand::isReg() const
000000000080c1e4 6 40.0000 MachineOperand.h:150
000000000080c1ec 2 13.3333 MachineOperand.h:150
...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76102 91177308-0d34-0410-b5e6-96231b3b80d8
means that two separate raw_ostreams are doing buffering before data is
sent to the underlying stream. Besides the inefficiency of redundant
buffering, the second level of buffering doesn't recieve flush()
requests.
Fix this by having formatted_raw_ostream set the underlying raw_ostream
to be unbuffered. This eliminates inefficiency due to redundant buffering,
and it makes the flush() disconnect harmless.
This fixes PR4559.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75883 91177308-0d34-0410-b5e6-96231b3b80d8
immediately on every output error. Instead, add a flag to
raw_ostream, and set the flag whenever an error is detected.
The flag can be queried and cleared from the public API. This
gives applications more flexibility to handling errors in
application-specific ways.
If the flag is not cleared when the raw_ostream is destructed,
llvm_report_error is called from the destructor. This ensures
that errors are not implicitly silenced, and provides
convenient default behavior for tools like llc and opt.
Clients wishing to avoid llvm_report_error calls from
raw_ostream should check for errors and clear the error flag.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75857 91177308-0d34-0410-b5e6-96231b3b80d8
an existing file is considered an error. Convert several tools
to use raw_fd_ostream instead of std::ostream, and to use this
new option instead of doing a manual check.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75801 91177308-0d34-0410-b5e6-96231b3b80d8
additional bug fixes:
1. The bug that everyone hit was a problem in the asmprinter where it
would remove $stub but keep the L prefix on a name when emitting the
indirect symbol. This is easy to fix by keeping the name of the stub
and the name of the symbol in a StringMap instead of just keeping a
StringSet and trying to reconstruct it late.
2. There was a problem printing the personality function. The current
logic to print out the personality function from the DWARF information
is a bit of a cesspool right now that duplicates a bunch of other
logic in the asm printer. The short version of it is that it depends
on emitting both the L and _ prefix for symbols (at least on darwin)
and until I can untangle it, it is best to switch the mangler back to
emitting both prefixes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75646 91177308-0d34-0410-b5e6-96231b3b80d8