When forming an IT block from the first MOV here:
%R2<def> = t2MOVr %R0, pred:1, pred:%CPSR, opt:%noreg
%R3<def> = tMOVr %R0<kill>, pred:14, pred:%noreg
the move in to R3 is moved out of the IT block so that later instructions on the same predicate can be inside this block, and we can share the IT instruction.
However, when moving the R3 copy out of the IT block, we need to clear its kill flags for anything in use at this point in time, ie, R0 here.
This appeases the machine verifier which thought that R0 wasn't defined when used.
I have a test case, but its extremely register allocator specific. It would be too fragile to commit a test which depends on the register allocator here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236468 91177308-0d34-0410-b5e6-96231b3b80d8
After r236465, Orc uses ValueMaterializer and so needs to link against TransformUtils to get the ValueMaterializer::anchor().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236467 91177308-0d34-0410-b5e6-96231b3b80d8
and avoid cloning unused decls into every partition.
Module partitioning showed up as a source of significant overhead when I
profiled some trivial test cases. Avoiding the overhead of partitionging
for uncalled functions helps to mitigate this.
This change also means that it is no longer necessary to have a
LazyEmittingLayer underneath the CompileOnDemand layer, since the
CompileOnDemandLayer will not extract or emit function bodies until they are
called.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236465 91177308-0d34-0410-b5e6-96231b3b80d8
These changes allow usages where you want to pass an additional
commandline option to all invocations of a specific llvm tool. Example:
> llvm-lit -Dllc=llc -enable-misched -verify-machineinstrs
Differential Revision: http://reviews.llvm.org/D9487
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236461 91177308-0d34-0410-b5e6-96231b3b80d8
When deciding whether a value comes from the aggregate or inserted value of an
insertvalue instruction, we compare the indices against those of the location
we're interested in. One of the lists needs reversing because the input data is
backwards (so that modifications take place at the end of the SmallVector), but
we were reversing both before leading to incorrect results.
Should fix PR23408
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236457 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The object format can be set to something other than MachO, e.g.
to use ELF-on-Darwin for MCJIT. This already works on Windows, so
there's no reason it shouldn't on Darwin.
Reviewers: lhames, grosbach
Subscribers: rafael, grosbach, t.p.northover, llvm-commits
Differential Revision: http://reviews.llvm.org/D6185
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236455 91177308-0d34-0410-b5e6-96231b3b80d8
A joined option always needs to have an argument, even if it's an empty one.
Clang would previously assert when trying to use --extra-warnings, which is
a flag alias for -W, which is a joined option.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236434 91177308-0d34-0410-b5e6-96231b3b80d8
At the moment, all subregs defined by the SystemZ target can be modified
independently of the wider register. E.g. writing to a GR32 does not
change the upper 32 bits of the GR64. Writing to an FP32 does not change
the lower 32 bits of the FP64.
Hoewver, the upcoming support for the vector extension redefines FP64 as
one half of a V128. Floating-point operations leave the other half of
a V128 in an unpredictable state, so it's no longer the case that writing
to an FP32 leaves the bits of the underlying register (the V128) alone.
I'd prefer to have separate subreg_ names for this situation, so that
it's obvious at a glance whether we're talking about a subreg that leaves
the other parts of the register alone.
No behavioral change intended.
Patch originally by Richard Sandiford.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236433 91177308-0d34-0410-b5e6-96231b3b80d8
We know what MemoryKind an operand has at the time we construct it,
so we might as well just record it in an unused part of the structure.
This makes it easier to add scatter/gather addresses later.
No behavioral change intended.
Patch originally by Richard Sandiford.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236432 91177308-0d34-0410-b5e6-96231b3b80d8
It seems SystemZTargetLowering::getTargetNodeName got out of sync with
some recent changes to the SystemZISD opcode list. Add back all the
missing opcodes (and re-sort to the same order as SystemISelLowering.h).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236430 91177308-0d34-0410-b5e6-96231b3b80d8
ScheduleDAGInstrs wasn't setting or clearing the kill flags on instructions inside bundles. This led to code such as this
%R3<def> = t2ANDrr %R0
BUNDLE %ITSTATE<imp-def,dead>, %R0<imp-use,kill>
t2IT 1, 24, %ITSTATE<imp-def>
R6<def,tied6> = t2ORRrr %R0<kill>, ...
being transformed to
BUNDLE %ITSTATE<imp-def,dead>, %R0<imp-use>
t2IT 1, 24, %ITSTATE<imp-def>
R6<def,tied6> = t2ORRrr %R0<kill>, ...
%R3<def> = t2ANDrr %R0<kill>
where the kill flag was removed from the BUNDLE instruction, but not the t2ORRrr inside it. The verifier then thought that
R0 was undefined when read by the AND.
This change make the toggleKillFlags method also check for bundles and toggle flags on bundled instructions.
Setting the kill flag is special cased as we only want to set the kill flag on the last instruction in the bundle.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236428 91177308-0d34-0410-b5e6-96231b3b80d8
Fixed some bugs in extend/truncate for AVX-512 target.
Removed VBROADCASTM (masked broadcast) node, since it is not used any more.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236420 91177308-0d34-0410-b5e6-96231b3b80d8
After r210687, windows_error does nothing but call mapWindowsError.
Other Windows/*.inc files directly call mapWindowsError. This patch
updates Path.inc and Process.inc to do the same.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236409 91177308-0d34-0410-b5e6-96231b3b80d8
Looking at coverage with an out of date profile can be confusing.
Provide a little hint that something might be wrong.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236408 91177308-0d34-0410-b5e6-96231b3b80d8
This is a followup from:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150323/268067.html
Upgrade instructions:
$ mv llvm/include/llvm/Config/config.h ./config.h.BACKUP
# copy the configure line from line 7 of llvm/config.log
# (for example: `$ ./configure --no-create --no-recursion`)
$ mkdir build
$ cd build
# run the configure line, but this time with '../llvm' at the beginning:
$ ../llvm/configure --no-create --no-recursion
These warnings will soon be turned into hard errors after a week. Speak up now
if this is going to be a problem for you.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236399 91177308-0d34-0410-b5e6-96231b3b80d8
Removed code that was replicating v8i16 'shift + mask' implementation that is done more nicely by making use of LowerScalarImmediateShift
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236388 91177308-0d34-0410-b5e6-96231b3b80d8
Seems we were setting the base address on the wrong DwarfCompileUnit
object so it wasn't being used when generating the ranges.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236377 91177308-0d34-0410-b5e6-96231b3b80d8
