- Emit DW_AT_byte_size for struct and union of size zero.
- Emit DW_AT_declaration for forward type declaration.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60812 91177308-0d34-0410-b5e6-96231b3b80d8
The Cost field is removed. It was only being used in a very limited way,
to indicate when the scheduler should attempt to protect a live register,
and it isn't really needed to do that. If we ever want the scheduler to
start inserting copies in non-prohibitive situations, we'll have to
rethink some things anyway.
A Latency field is added. Instead of giving each node a single
fixed latency, each edge can have its own latency. This will eventually
be used to model various micro-architecture properties more accurately.
The PointerIntPair class and an internal union are now used, which
reduce the overall size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60806 91177308-0d34-0410-b5e6-96231b3b80d8
target-independent way of determining overflow on multiplication. It's very
tricky. Patch by Zoltan Varga!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60800 91177308-0d34-0410-b5e6-96231b3b80d8
essential problem was that the DAG can contain
random unused nodes which were never analyzed.
When remapping a value of a node being processed,
such a node may become used and need to be analyzed;
however due to operands being transformed during
analysis the node may morph into a different one.
Users of the morphing node need to be updated, and
this wasn't happening. While there I added a bunch
of documentation and sanity checks, so I (or some
other poor soul) won't have to scratch their head
over this stuff so long trying to remember how it
was all supposed to work next time some obscure
problem pops up! The extra sanity checking exposed
a few places where invariants weren't being preserved,
so those are fixed too. Since some of the sanity
checking is expensive, I added a flag to turn it
on. It is also turned on when building with
ENABLE_EXPENSIVE_CHECKS=1.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60797 91177308-0d34-0410-b5e6-96231b3b80d8
Fix the shift amount when unrolling a vector shift into scalar shifts.
Fix problem in getShuffleScalarElt where it assumes that the input of
a bit convert must be a vector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60740 91177308-0d34-0410-b5e6-96231b3b80d8
and use it in x86 address mode folding. Also, make
getRegForValue return 0 for illegal types even if it has a
ValueMap for them, because Argument values are put in the
ValueMap. This fixes PR3181.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60696 91177308-0d34-0410-b5e6-96231b3b80d8
changing the stack slots on an instruction, to keep them
consistent with the actual memory addresses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60584 91177308-0d34-0410-b5e6-96231b3b80d8
While they appear to provide a normal clobbering def, they don't
in the case of the awkward IMPLICIT_DEF+INSERT_SUBREG idiom. It
would be good to change INSERT_SUBREG; until then, this change
allows post-regalloc scheduling to cope in a mildly conservative
way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60583 91177308-0d34-0410-b5e6-96231b3b80d8
is set but mayLoad is not set. Fix all the problems this turned up.
Change code to not use isSimpleLoad instead of mayLoad unless it
really wants isSimpleLoad.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60459 91177308-0d34-0410-b5e6-96231b3b80d8
1. ppcf128 select is expanded to f64 select's.
2. f64 select operand 0 is an i1 truncate, it's promoted to i32 zero_extend.
3. f64 select is updated. It's changed back to a "NewNode" and being re-analyzed.
4. f64 select operands are being processed. Operand 0 is a "NewNode". It's being expunged out of ReplacedValues map.
5. ExpungeNode tries to remap f64 select and notice it's a "NewNode" and assert.
Duncan, please take a look. Thanks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60443 91177308-0d34-0410-b5e6-96231b3b80d8
MERGE_VALUES node with only one operand, so get
rid of special code that only existed to handle
that possibility.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60349 91177308-0d34-0410-b5e6-96231b3b80d8
ReplaceNodeResults: rather than returning a node which
must have the same number of results as the original
node (which means mucking around with MERGE_VALUES,
and which is also easy to get wrong since SelectionDAG
folding may mean you don't get the node you expect),
return the results in a vector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60348 91177308-0d34-0410-b5e6-96231b3b80d8
multiplies.
Some more cleverness would be nice, though. It would be nice if we
could do this transformation on illegal types. Also, we would
prefer a narrower constant when possible so that we can use a narrower
multiply, which can be cheaper.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60283 91177308-0d34-0410-b5e6-96231b3b80d8
nearby FIXME.
I'm not sure what the right way to fix the Cell test was; if the
approach I used isn't okay, please let me know.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60277 91177308-0d34-0410-b5e6-96231b3b80d8
Despite changing the order of evaluation, this doesn't actually change the
meaning of the statement.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60177 91177308-0d34-0410-b5e6-96231b3b80d8
and the LiveInterval.h top-level comment and accordingly. This fixes blocks
having spurious live-in registers in boundary cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60092 91177308-0d34-0410-b5e6-96231b3b80d8
introduce any new spilling; it just uses unused registers.
Refactor the SUnit topological sort code out of the RRList scheduler and
make use of it to help with the post-pass scheduler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59999 91177308-0d34-0410-b5e6-96231b3b80d8
- Mark "add with overflow" as having a custom lowering for X86. Give it a null
lowering representation for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59971 91177308-0d34-0410-b5e6-96231b3b80d8
(this doesn't happen that often, since most code
does not use illegal types) then follow it by a
DAG combiner run that is allowed to generate
illegal operations but not illegal types. I didn't
modify the target combiner code to distinguish like
this between illegal operations and illegal types,
so it will not produce illegal operations as well
as not producing illegal types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59960 91177308-0d34-0410-b5e6-96231b3b80d8
"It simplifies the type legalization part a bit, and produces better code by
teaching SelectionDAG about the extra bits in an i8 SADDO/UADDO node. In
essence, I spontaneously decided that on x86 this i8 boolean result would be
either 0 or 1, and on other platforms 0/1 or 0/-1, depending on whether the
platform likes it's boolean zero extended or sign extended."
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59864 91177308-0d34-0410-b5e6-96231b3b80d8
g++ -m32 -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wmissing-format-attribute -fno-common -mdynamic-no-pic -DHAVE_CONFIG_H -Wno-unused -DTARGET_NAME=\"i386-apple-darwin9.5.0\" -I. -I. -I../../llvm-gcc.src/gcc -I../../llvm-gcc.src/gcc/. -I../../llvm-gcc.src/gcc/../include -I./../intl -I../../llvm-gcc.src/gcc/../libcpp/include -I../../llvm-gcc.src/gcc/../libdecnumber -I../libdecnumber -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.obj/include -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.src/include -DENABLE_LLVM -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.obj/../llvm.src/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -I. -I. -I../../llvm-gcc.src/gcc -I../../llvm-gcc.src/gcc/. -I../../llvm-gcc.src/gcc/../include -I./../intl -I../../llvm-gcc.src/gcc/../libcpp/include -I../../llvm-gcc.src/gcc/../libdecnumber -I../libdecnumber -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.obj/include -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.src/include ../../llvm-gcc.src/gcc/llvm-types.cpp -o llvm-types.o
../../llvm-gcc.src/gcc/llvm-convert.cpp: In member function 'void TreeToLLVM::EmitMemCpy(llvm::Value*, llvm::Value*, llvm::Value*, unsigned int)':
../../llvm-gcc.src/gcc/llvm-convert.cpp:1496: error: 'memcpy_i32' is not a member of 'llvm::Intrinsic'
../../llvm-gcc.src/gcc/llvm-convert.cpp:1496: error: 'memcpy_i64' is not a member of 'llvm::Intrinsic'
../../llvm-gcc.src/gcc/llvm-convert.cpp: In member function 'void TreeToLLVM::EmitMemMove(llvm::Value*, llvm::Value*, llvm::Value*, unsigned int)':
../../llvm-gcc.src/gcc/llvm-convert.cpp:1512: error: 'memmove_i32' is not a member of 'llvm::Intrinsic'
../../llvm-gcc.src/gcc/llvm-convert.cpp:1512: error: 'memmove_i64' is not a member of 'llvm::Intrinsic'
../../llvm-gcc.src/gcc/llvm-convert.cpp: In member function 'void TreeToLLVM::EmitMemSet(llvm::Value*, llvm::Value*, llvm::Value*, unsigned int)':
../../llvm-gcc.src/gcc/llvm-convert.cpp:1528: error: 'memset_i32' is not a member of 'llvm::Intrinsic'
../../llvm-gcc.src/gcc/llvm-convert.cpp:1528: error: 'memset_i64' is not a member of 'llvm::Intrinsic'
make[3]: *** [llvm-convert.o] Error 1
make[3]: *** Waiting for unfinished jobs....
rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gpl.pod gcc.pod
make[2]: *** [all-stage1-gcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59809 91177308-0d34-0410-b5e6-96231b3b80d8
because the boolean it returns to indicate an overflow may not be treated like
as a flag. It could be stored to memory, for instance.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59780 91177308-0d34-0410-b5e6-96231b3b80d8
"ISD::ADDO". ISD::ADDO is lowered into a target-independent form that does the
addition and then checks if the result is less than one of the operands. (If it
is, then there was an overflow.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59779 91177308-0d34-0410-b5e6-96231b3b80d8
schedulers. This doesn't have much immediate impact because
targets that use these schedulers by default don't yet provide
pipeline information.
This code also didn't have the benefit of register pressure
information. Also, removing it will avoid problems with list-burr
suddenly starting to do latency-oriented scheduling on x86 when we
start providing pipeline data, which would increase spilling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59775 91177308-0d34-0410-b5e6-96231b3b80d8
some of the latency computation logic out of the SDNode
ScheduleDAG code into a TargetInstrItineraries helper method
to help with this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59761 91177308-0d34-0410-b5e6-96231b3b80d8
the RR scheduler actually does look at latency values, but it
doesn't use a hazard recognizer so it has no way to know when
a no-op is needed, as opposed to just stalling and incrementing
the cycle count.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59759 91177308-0d34-0410-b5e6-96231b3b80d8
MachineInstr scheduling DAG, meaning they implicitly depend on all
preceding defs. This fixes Benchmarks/Shootout-C++/except and
Regression/C++/EH/simple_rethrow in
-relocation-model=pic -disable-post-RA-scheduler=false
mode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59747 91177308-0d34-0410-b5e6-96231b3b80d8
dedicated "fast" scheduler in -fast mode instead, which is
faster. This speeds up llc -fast by a few percent on some
testcases -- the speedup only happens for code not handled by
fast-isel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59700 91177308-0d34-0410-b5e6-96231b3b80d8
- When scavenging a register, in addition to the spill, insert a restore before the first use.
- Abort if client is looking to scavenge a register even when a previously scavenged register is still live.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59697 91177308-0d34-0410-b5e6-96231b3b80d8
is currently off by default, and can be enabled with
-disable-post-RA-scheduler=false.
This doesn't have a significant impact on most code yet because it doesn't
yet do anything to address anti-dependencies and it doesn't attempt to
disambiguate memory references. Also, several popular targets
don't have pipeline descriptions yet.
The majority of the changes here are splitting the SelectionDAG-specific
code out of ScheduleDAG, so that ScheduleDAG can be moved to
libLLVMCodeGen.a. The interface between ScheduleDAG-using code and
the rest of the scheduling code is somewhat rough and will evolve.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59676 91177308-0d34-0410-b5e6-96231b3b80d8
and FP_ROUND. Not sure what these were doing
here - probably they were sometimes (wrongly)
created with integer operands somewhere that
has since been fixed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59548 91177308-0d34-0410-b5e6-96231b3b80d8
SCALAR_TO_VECTOR. I didn't add the testcase, because
once llc gets past scalar-to-vector it hits a SPU target
lowering bug and explodes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59530 91177308-0d34-0410-b5e6-96231b3b80d8
new CycleBound value. Instead, just update CycleBound on each call.
Also, make ReleasePred and ReleaseSucc methods more consistent accross
the various schedulers.
This also happens to make ScheduleDAGRRList's CycleBound computation
somewhat more interesting, though it still doesn't have any noticeable
effect, because no current targets that use the register-pressure
reduction scheduler provide pipeline models.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59475 91177308-0d34-0410-b5e6-96231b3b80d8
use SHUFFLE_VECTOR instead. If not practical, fall back
to the old scheme of building the split result by hand
using a BUILD_VECTOR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59361 91177308-0d34-0410-b5e6-96231b3b80d8
and when loading/storing a widen vector, make sure that they are loaded
and stored in consecutive order.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59357 91177308-0d34-0410-b5e6-96231b3b80d8
fairly conservative; it doesn't do alias-analysis queries and it doesn't
attempt to break anti-dependencies.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59324 91177308-0d34-0410-b5e6-96231b3b80d8
to carry a SmallVector of flagged nodes, just calculate the flagged nodes
dynamically when they are needed.
The local-liveness change is due to a trivial scheduling change where
the scheduler arbitrary decision differently.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59273 91177308-0d34-0410-b5e6-96231b3b80d8
special-purpose hook to a new pass. Also, add check to see if any
x87 virtual registers are used, to avoid doing any work in the
common case that no x87 code is needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59190 91177308-0d34-0410-b5e6-96231b3b80d8
that it no longer handles non-power-of-two vectors.
However it previously only handled them sometimes,
depending on obscure numerical relationships between
the index and vector type. For example, for a vector
of length 6, it would succeed if and only if the
index was an even multiple of 6. I consider this
more confusing than useful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59122 91177308-0d34-0410-b5e6-96231b3b80d8
before creating the SUnit for the operation that it was unfolded from. This
allows each SUnit to have all of its predecessor SUnits available at the time
it is created. I don't know yet if this will be absolutely required, but it
is a little tidier to do it this way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59083 91177308-0d34-0410-b5e6-96231b3b80d8
argument instead of taking the SelectionDAG's TargetMachine. This is
needed for some upcoming scheduler changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59055 91177308-0d34-0410-b5e6-96231b3b80d8
The CC was changed, but wasn't checked to see if it was legal if the DAG
combiner was being run after legalization. Threw in a couple of checks just to
make sure that it's okay. As far as the PR is concerned, no back-end target
actually exhibited this problem, so there isn't an associated testcase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59035 91177308-0d34-0410-b5e6-96231b3b80d8
support targets that support these conversions. Users should avoid using
this node as the current targets don't generating code for it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59001 91177308-0d34-0410-b5e6-96231b3b80d8
where the argument is an apint, or smaller than the minimum
size for which there is a libcall (i32).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58994 91177308-0d34-0410-b5e6-96231b3b80d8
inform the optimizers that the result must be zero/
sign extended from the smaller type. For example,
if a fp to unsigned i16 is promoted to fp to i32,
then we are allowed to assume that the extra 16 bits
are zero (because the result of fp to i16 is undefined
if the result does not fit in an i16). This is
quite aggressive, but should help the optimizers
produce better code. This requires correcting a
test which thought that fp_to_uint is some kind
of truncation, which it is not: in the testcase
(which does fp to i1), either the fp value converts
to 0 or 1 or the result is undefined, which is
quite different to truncation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58991 91177308-0d34-0410-b5e6-96231b3b80d8
an array that is empty. Instead of requiring this array, allow a null pointer.
This shrinks all forward references of structs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58959 91177308-0d34-0410-b5e6-96231b3b80d8
FIXME: it seems, that most of targets don't support
offsets wrt CPI/GlobalAddress', was it intentional?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58917 91177308-0d34-0410-b5e6-96231b3b80d8
This is Chris' patch from the PR, modified to realize that
SETUGT/SETULT occur legitimately with integers, plus
two fixes in LegalizeDAG to pass a valid result type into
LegalizeSetCC. The argument of TLI.getSetCCResultType is
ignored on PPC, but I think I'm following usage elsewhere.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58871 91177308-0d34-0410-b5e6-96231b3b80d8
the condition for a BRCOND, according to what is
returned by getSetCCResultContents. Since all
targets return the same thing (ZeroOrOneSetCCResult),
this should be harmless! The point is that all over
the place the result of SETCC is fed directly into
BRCOND. On machines for which getSetCCResultContents
returns ZeroOrNegativeOneSetCCResult, this is a
sign-extended boolean. So it seems dangerous to
also feed BRCOND zero-extended booleans in some
circumstances - for example, when promoting the
condition.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58861 91177308-0d34-0410-b5e6-96231b3b80d8
(e.g. a bitfield test) narrow the load as much as possible.
The has the potential to avoid unnecessary partial-word
load-after-store conflicts, which cause stalls on several targets.
Also a size win on x86 (testb vs testl).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58825 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM IR code and not in the selection DAG ISel. This is a cleaner solution.
- Fix the heuristic for determining if protectors are necessary. The previous
one wasn't checking the proper type size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58824 91177308-0d34-0410-b5e6-96231b3b80d8
- Get rid of "HasStackProtector" in MachineFrameInfo.
- Modify intrinsics to tell which are doing what with memory.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58799 91177308-0d34-0410-b5e6-96231b3b80d8
- stackprotector_prologue creates a stack object and stores the guard there.
- stackprotector_epilogue reads the stack guard from the stack position created
by stackprotector_prologue.
- The PrologEpilogInserter was changed to make sure that the stack guard is
first on the stack frame.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58791 91177308-0d34-0410-b5e6-96231b3b80d8
"getOrInsertFunction" in that it either adds a new declaration of the global
and returns it, or returns the current one -- optionally casting it to the
correct type.
- Use the new getOrInsertGlobal in the stack protector code.
- Use "splitBasicBlock" in the stack protector code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58727 91177308-0d34-0410-b5e6-96231b3b80d8
- Use enums instead of magic numbers.
- Rework algorithm to use the bytes size from the target to determine when to
emit stack protectors.
- Get rid of "propolice" in any comments.
- Renamed an option to its expanded form.
- Other miscellanenous changes.
More changes will come after this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58723 91177308-0d34-0410-b5e6-96231b3b80d8
* The prologue is modified to read the __stack_chk_guard global and insert it
onto the stack.
* The epilogue is modified to read the stored guard from the stack and compare
it to the original __stack_chk_guard value. If they differ, then the
__stack_chk_fail() function is called.
* The stack protector needs to be first on the stack (after the parameters) to
catch any stack-smashing activities.
Front-end support will follow after a round of beta testing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58673 91177308-0d34-0410-b5e6-96231b3b80d8
sized integers like i129, and also reduce the number
of assumptions made about how vaarg is implemented.
This still doesn't work correctly for small integers
like (eg) i1 on x86, since x86 passes each of them
(essentially an i8) in a 4 byte stack slot, so the
pointer needs to be advanced by 4 bytes not by 1 byte
as now. But this is no longer a LegalizeTypes problem
(it was also wrong in LT before): it is a bug in the
operation expansion in LegalizeDAG: now LegalizeTypes
turns an i1 vaarg into an i8 vaarg which would work
fine if only the i8 vaarg was turned into correct code
later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58635 91177308-0d34-0410-b5e6-96231b3b80d8
exist before. Updating the live intervals in that care is tricky in the general
case.
Evan, if you see a tighter guard condition for this, let me know.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58560 91177308-0d34-0410-b5e6-96231b3b80d8
callee-saved restore code. It could skip over conditional jumps
accidentally. Instead, just skip the "return" instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58489 91177308-0d34-0410-b5e6-96231b3b80d8
type for the shift amount type. Add a check
that shifts and rotates use the type returned
by getShiftAmountTy for the amount. This
exposed some problems in CellSPU and PPC,
which have already been fixed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58455 91177308-0d34-0410-b5e6-96231b3b80d8
other day that PPC custom lowering could create
a BUILD_PAIR of two f64 with a result type of...
f64! - already fixed). Fix a place that triggers
the sanity check.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58378 91177308-0d34-0410-b5e6-96231b3b80d8
