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
