Summary:
These correspond to IMAGE_LOAD/STORE[_MIP] and are going to be used by Mesa
for the GL_ARB_shader_image_load_store extension.
IMAGE_LOAD is already matched by llvm.SI.image.load. That intrinsic has
a legacy name and pretends not to read memory.
Differential Revision: http://reviews.llvm.org/D17276
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261224 91177308-0d34-0410-b5e6-96231b3b80d8
Compiling Hexagon target with GCC 6 produces "error: should have been
declared inside" due to GCC PR c++/69657 which was merged.
Properly wrapping operator<<() definitions within the namespace llvm
fixes the issue.
Author: domagoj.stolfa
Differential Revision: http://reviews.llvm.org/D17281
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261220 91177308-0d34-0410-b5e6-96231b3b80d8
Commit r259357 was reverted because it caused PR26629. We were assuming all
roots of a vectorizable tree could be truncated to the same width, which is not
the case in general. This commit reapplies the patch along with a fix and a new
test case to ensure we don't regress because of this issue again. This should
fix PR26629.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261212 91177308-0d34-0410-b5e6-96231b3b80d8
This avoids a operator precedence warning for mixing + and | in an
expression. I checked that this matches the definition in the Split
DWARF proposal.
Patch by Cong Liu!
Differential Revision: http://reviews.llvm.org/D17375
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261207 91177308-0d34-0410-b5e6-96231b3b80d8
convert one test to use this.
This is a particularly significant milestone because it required
a working per-function AA framework which can be queried over each
function from within a CGSCC transform pass (and additionally a module
analysis to be accessible). This is essentially *the* point of the
entire pass manager rewrite. A CGSCC transform is able to query for
multiple different function's analysis results. It works. The whole
thing appears to actually work and accomplish the original goal. While
we were able to hack function attrs and basic-aa to "work" in the old
pass manager, this port doesn't use any of that, it directly leverages
the new fundamental functionality.
For this to work, the CGSCC framework also has to support SCC-based
behavior analysis, etc. The only part of the CGSCC pass infrastructure
not sorted out at this point are the updates in the face of inlining and
running function passes that mutate the call graph.
The changes are pretty boring and boiler-plate. Most of the work was
factored into more focused preperatory patches. But this is what wires
it all together.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261203 91177308-0d34-0410-b5e6-96231b3b80d8
In cases where the PSHUFB shuffle mask is shared it might not be bitcasted to a vXi8 byte vector. This patch adds support for decoding these wider shuffle masks from the ConstantPool.
The test case in question makes use of this to recognise the shuffle mask is an unary UNPCKL pattern and simplifies accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261201 91177308-0d34-0410-b5e6-96231b3b80d8
analysis passes, support pre-registering analyses, and use that to
implement parsing and pre-registering a custom alias analysis pipeline.
With this its possible to configure the particular alias analysis
pipeline used by the AAManager from the commandline of opt. I've updated
the test to show this effectively in use to build a pipeline including
basic-aa as part of it.
My big question for reviewers are around the APIs that are used to
expose this functionality. Are folks happy with pass-by-lambda to do
pass registration? Are folks happy with pre-registering analyses as
a way to inject customized instances of an analysis while still using
the registry for the general case?
Other thoughts of course welcome. The next round of patches will be to
add the rest of the alias analyses into the new pass manager and wire
them up here so that they can be used from opt. This will require
extending the (somewhate limited) functionality of AAManager w.r.t.
module passes.
Differential Revision: http://reviews.llvm.org/D17259
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261197 91177308-0d34-0410-b5e6-96231b3b80d8
Lit tends to find out-of-date unittests in the build tree.
FIXME: It may be reverted several days after.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261194 91177308-0d34-0410-b5e6-96231b3b80d8
While we still do want reducible control flow, the RequiresStructuredCFG
flag imposes more strict structure constraints than WebAssembly wants.
Unsetting this flag enables critical edge splitting and tail merging.
Also, disable TailDuplication explicitly, as it doesn't support virtual
registers, and was previously only disabled by the RequiresStructuredCFG
flag.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261190 91177308-0d34-0410-b5e6-96231b3b80d8
The commit breaks stage2 compilation on PowerPC. Reverting for now while
this is analyzed. I also have to revert the LiveIntervalTest for now as
that depends on this commit.
Revert "LiveIntervalAnalysis: Remove LiveVariables requirement"
This reverts commit r260806.
Revert "Remove an unnecessary std::move to fix -Wpessimizing-move warning."
This reverts commit r260931.
Revert "Fix typo in LiveIntervalTest"
This reverts commit r260907.
Revert "Add unittest for LiveIntervalAnalysis::handleMove()"
This reverts commit r260905.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261189 91177308-0d34-0410-b5e6-96231b3b80d8
Changes:
- Added disassembler project
- Fixed all decoding conflicts in .td files
- Added DecoderMethod=“NONE” option to Target.td that allows to
disable decoder generation for an instruction.
- Created decoding functions for VS_32 and VReg_32 register classes.
- Added stubs for decoding all register classes.
- Added several tests for disassembler
Disassembler only supports:
- VI subtarget
- VOP1 instruction encoding
- 32-bit register operands and inline constants
[Valery]
One of the point that requires to pay attention to is how decoder
conflicts were resolved:
- Groups of target instructions were separated by using different
DecoderNamespace (SICI, VI, CI) using similar to AssemblerPredicate
approach.
- There were conflicts in IMAGE_<> instructions caused by two
different reasons:
1. dmask wasn’t specified for the output (fixed)
2. There are image instructions that differ only by the number of
the address components but have the same encoding by the HW spec. The
actual number of address components is determined by the HW at runtime
using image resource descriptor starting from the VGPR encoded in an
IMAGE instruction. This means that we should choose only one instruction
from conflicting group to be the rule for decoder. I didn’t find the way
to disable decoder generation for an arbitrary instruction and therefore
made a onelinear fix to tablegen generator that would suppress decoder
generation when DecoderMethod is set to “NONE”. This is a change that
should be reviewed and submitted first. Otherwise I would need to
specify different DecoderNamespace for every instruction in the
conflicting group. I haven’t checked yet if DecoderMethod=“NONE” is not
used in other targets.
3. IMAGE_GATHER decoder generation is for now disabled and to be
done later.
[/Valery]
Patch By: Sam Kolton
Differential Revision: http://reviews.llvm.org/D16723
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261185 91177308-0d34-0410-b5e6-96231b3b80d8
These passes are optimizations, and should be disabled when not
optimizing.
Also create an MCCodeGenInfo so the opt level is correctly plumbed to
the backend pass manager.
Also remove the command line flag for disabling register coloring;
running llc with -O0 should now be useful for debugging, so it's not
necessary.
Differential Revision: http://reviews.llvm.org/D17327
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261176 91177308-0d34-0410-b5e6-96231b3b80d8
After r261154, we were only clearing flags if the known-zero register was
originally live-in to the basic block, but we have to do it even if not when
more than one COPY has been eliminated, otherwise the user of the first COPY
may still have <kill> marked.
E.g.
BB#N:
%X0 = COPY %XZR
STRXui %X0<kill>, <fi#0>
%X0 = COPY %XZR
STRXui %X0<kill>, <fi#1>
We can eliminate both copies, X0 is not live-in, but we must clear the kill on
the first store.
Unfortunately, I've been unable to come up with a non-fragile test for this.
I've only seen it in the wild with regalloc-created spills, and attempts to
reproduce that in a reasonable way run afoul of COPY coalescing. Even volatile
asm clobbers were moved around. Should fix the aarch64 bot though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261175 91177308-0d34-0410-b5e6-96231b3b80d8
Also implements the PDBSymbolCompilandEnv::getValue() method,
which until now had been unimplemented specifically because
variant did not support string values.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261173 91177308-0d34-0410-b5e6-96231b3b80d8
Mostly, this fixes the bug that if the CBZ guaranteed Xn but Wn was used, we
didn't sort out the use-def chain properly.
I've also made it check more than just the last instruction for a compatible
CBZ (so it can cope without fallthroughs). I'd have liked to do that
separately, but it's helps writing the test.
Finally, I removed some custom loops in favour of MachineInstr helpers and
refactored the control flow to flatten it and avoid possibly quadratic
iterations in blocks with many copies. NFC for these, just a general tidy-up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261154 91177308-0d34-0410-b5e6-96231b3b80d8
Every symbol, no matter what it's tag is, supports the method
getSymIndexId(). However, this was being forwarded on every
concrete symbol type, so if someone had a PDBSymbol that they
didn't know what type it was (or simply didn't have an instance
of the concrete symbol type), they would not be able to get its
index id. This patch moves the method up to PDBSymbol, so that
no matter what type of object you have, you can always get its
id.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261153 91177308-0d34-0410-b5e6-96231b3b80d8
The IDiaSymbol::getValue() method returns a variant. Until now,
I had never encountered a string value, so the Variant wrapper
did not support VT_BSTR. Now we have need to support string
values, so this patch just adds support for one extra type to
Variant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261152 91177308-0d34-0410-b5e6-96231b3b80d8
This function is used to check whether a dbg.value intrinsic has already
been inserted, but without comparing the DIExpression, it would erroneously
fire on split aggregates and only the first scalar would survive.
Found via http://reviews.llvm.org/D16867.
<rdar://problem/24456528>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261145 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Store and loads unpacked by instcombine do not always have the right alignement. This explicitely compute the alignement and set it.
Reviewers: dblaikie, majnemer, reames, hfinkel, joker.eph
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17326
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261139 91177308-0d34-0410-b5e6-96231b3b80d8
When support for objc_unsafeClaimAutoreleasedReturnValue has been added to the
ARC optimizer in r258970, one case was missed which would lead the optimizer
to execute an llvm_unreachable. In this case, just handle ClaimRV in the same
way we handle RetainRV.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261134 91177308-0d34-0410-b5e6-96231b3b80d8
