| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: As per title. There was a lot of part missing in the C API, so I had to extend the invoke and landingpad API.
Reviewers: echristo, joker.eph, Wallbraker
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17359
llvm-svn: 261254
|
|
|
|
| |
llvm-svn: 261250
|
|
|
|
|
|
|
|
|
|
|
|
| |
These atomic operations are conceptually both a load and store from the same location. As such, we can treat them as the most conservative of those two components which in practice, means we can treat them like stores. An cmpxchg or atomicrmw captures the values, but not the locations accessed.
Note: We can probably be more aggressive about the comparison value in an cmpxhg since to have it be in memory, it must already be captured, but I figured it was better to avoid that for the moment.
Note 2: It turns out that since we don't actually support cmpxchg of pointer type, writing a negative test is impossible.
Differential Revision: http://reviews.llvm.org/D17400
llvm-svn: 261245
|
|
|
|
|
|
|
| |
This patch adds a variety of different methods to query source
and line number information from PDB files.
llvm-svn: 261239
|
|
|
|
|
|
|
| |
Since the behaviour is now different between Darwin and non-Darwin,
more triples are needed :-/
llvm-svn: 261238
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17379
llvm-svn: 261237
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In r260133, LLVM was changed to no longer extend i8/i16 return values,
as it's not required by the ABI. However, code was found in the wild
that relies on the old behaviour on Darwin, so this commit reverts
back to that old behaviour for Darwin.
On other platforms, it's less likely that code would be depending on
the old behaviour, as GCC and MSVC haven't been extending such return
values.
llvm-svn: 261235
|
|
|
|
| |
llvm-svn: 261234
|
|
|
|
| |
llvm-svn: 261232
|
|
|
|
|
|
|
|
|
|
|
|
| |
covmap needs to created as non allocatable, but not with
SHT_NOTE. The latter was needed to workaround a problem
of BFD linker with gc, which is no longer needed. (A more
proper longer term fix requires changing FE driver to force
referencing the section using linker script).
Differential Revision: http://reviews.llvm.org/D17309
llvm-svn: 261228
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 261224
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 261220
|
|
|
|
|
|
| |
Patch by Anand Kodnani.
llvm-svn: 261218
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 261212
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D16849
llvm-svn: 261211
|
|
|
|
| |
llvm-svn: 261210
|
|
|
|
| |
llvm-svn: 261208
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 261207
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 261203
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 261201
|
|
|
|
| |
llvm-svn: 261200
|
|
|
|
| |
llvm-svn: 261199
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17024
llvm-svn: 261198
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 261197
|
|
|
|
|
|
|
| |
Lit tends to find out-of-date unittests in the build tree.
FIXME: It may be reverted several days after.
llvm-svn: 261194
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 261190
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LiveIntervalTest
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.
llvm-svn: 261189
|
|
|
|
|
|
| |
used by asserts. NFC
llvm-svn: 261188
|
|
|
|
|
|
| |
immediates is handled by RawFrmImm8/RawFrmImm16.
llvm-svn: 261187
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 261185
|
|
|
|
| |
llvm-svn: 261184
|
|
|
|
| |
llvm-svn: 261177
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 261176
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 261175
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: As per title.
Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17245
llvm-svn: 261174
|
|
|
|
|
|
|
|
| |
Also implements the PDBSymbolCompilandEnv::getValue() method,
which until now had been unimplemented specifically because
variant did not support string values.
llvm-svn: 261173
|
|
|
|
| |
llvm-svn: 261172
|
|
|
|
| |
llvm-svn: 261170
|
|
|
|
| |
llvm-svn: 261169
|
|
|
|
|
|
|
|
|
|
|
| |
described by an immediate.
Found via http://reviews.llvm.org/D16867
Thanks to Paul Robinson for pointing this out.
<rdar://problem/24456528>
llvm-svn: 261168
|
|
|
|
|
|
|
|
| |
belonging to a single DBG_VALUE instruction.
NFC
llvm-svn: 261167
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: As per title
Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17249
llvm-svn: 261164
|
|
|
|
|
|
| |
to trace-bb, but has a different API. We already use the equivalent flag in GCC for Linux kernel fuzzing. We may be able to use this flag with AFL too
llvm-svn: 261159
|
|
|
|
| |
llvm-svn: 261156
|
|
|
|
| |
llvm-svn: 261155
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 261154
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 261153
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 261152
|
|
|
|
|
|
| |
This is to fix PR26645.
llvm-svn: 261149
|
|
|
|
|
|
|
|
|
|
|
| |
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>
llvm-svn: 261145
|