| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
Add Go bindings for CoroEarly, CoroSplit, CoroElide and CoroCleanup.
Differential Revision: https://reviews.llvm.org/D50951
llvm-svn: 340148
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D50950
llvm-svn: 340147
|
|
|
|
|
|
|
|
|
|
|
| |
Added DIFlags in LLVMDIBuilderCreateBasicType to add optional DWARF
attributes, such as DW_AT_endianity.
Patch by Chirag Patel.
Differential Revision: https://reviews.llvm.org/D50832
llvm-svn: 340146
|
|
|
|
| |
llvm-svn: 340145
|
|
|
|
|
|
| |
splat vector constants.
llvm-svn: 340144
|
|
|
|
|
|
|
|
|
|
| |
BITCAST nodes
Only adds support to the existing 'large element' scalar/vector to 'small element' vector bitcasts.
The next step would be to support cases where the large elements aren't all sign bits, and determine the small element equivalent based on the demanded elements.
llvm-svn: 340143
|
|
|
|
| |
llvm-svn: 340142
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a partial retry of rL340137 (reverted at rL340138 because of gcc host compiler crashing)
with 1 change:
Remove the changes to make microsoft builtins also use the LLVM intrinsics.
This exposes the LLVM funnel shift intrinsics as more familiar bit rotation functions in clang
(when both halves of a funnel shift are the same value, it's a rotate).
We're free to name these as we want because we're not copying gcc, but if there's some other
existing art (eg, the microsoft ops) that we want to replicate, we can change the names.
The funnel shift intrinsics were added here:
https://reviews.llvm.org/D49242
With improved codegen in:
https://reviews.llvm.org/rL337966
https://reviews.llvm.org/rL339359
And basic IR optimization added in:
https://reviews.llvm.org/rL338218
https://reviews.llvm.org/rL340022
...so these are expected to produce asm output that's equal or better to the multi-instruction
alternatives using primitive C/IR ops.
In the motivating loop example from PR37387:
https://bugs.llvm.org/show_bug.cgi?id=37387#c7
...we get the expected 'rolq' x86 instructions if we substitute the rotate builtin into the source.
Differential Revision: https://reviews.llvm.org/D50924
llvm-svn: 340141
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes definitions of vld and vst NEON intrinsics so
that we only define them if half-precision arithmetic is
supported on the target platform, as prescribed in ACLE 2.0.
Differential Revision: https://reviews.llvm.org/D49075
llvm-svn: 340140
|
|
|
|
|
|
| |
demanded elts through a bitcast
llvm-svn: 340139
|
|
|
|
|
|
| |
At least a couple of bots (gcc host compiler on PPC only?) are showing the compiler dying while trying to compile.
llvm-svn: 340138
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a retry of rL340135 (reverted at rL340136 because of gcc host compiler crashing)
with 2 changes:
1. Move the code into a helper to reduce code duplication (and hopefully work-around the crash).
2. The original commit had a formatting bug in the docs (missing an underscore).
Original commit message:
This exposes the LLVM funnel shift intrinsics as more familiar bit rotation functions in clang
(when both halves of a funnel shift are the same value, it's a rotate).
We're free to name these as we want because we're not copying gcc, but if there's some other
existing art (eg, the microsoft ops that are modified in this patch) that we want to replicate,
we can change the names.
The funnel shift intrinsics were added here:
https://reviews.llvm.org/D49242
With improved codegen in:
https://reviews.llvm.org/rL337966
https://reviews.llvm.org/rL339359
And basic IR optimization added in:
https://reviews.llvm.org/rL338218
https://reviews.llvm.org/rL340022
...so these are expected to produce asm output that's equal or better to the multi-instruction
alternatives using primitive C/IR ops.
In the motivating loop example from PR37387:
https://bugs.llvm.org/show_bug.cgi?id=37387#c7
...we get the expected 'rolq' x86 instructions if we substitute the rotate builtin into the source.
Differential Revision: https://reviews.llvm.org/D50924
llvm-svn: 340137
|
|
|
|
|
|
|
|
| |
At least a couple of bots (PPC only?) are showing the compiler dying while trying to compile:
http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/11065/steps/build%20stage%201/logs/stdio
http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt/builds/18267/steps/build%20stage%201/logs/stdio
llvm-svn: 340136
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This exposes the LLVM funnel shift intrinsics as more familiar bit rotation functions in clang
(when both halves of a funnel shift are the same value, it's a rotate).
We're free to name these as we want because we're not copying gcc, but if there's some other
existing art (eg, the microsoft ops that are modified in this patch) that we want to replicate,
we can change the names.
The funnel shift intrinsics were added here:
D49242
With improved codegen in:
rL337966
rL339359
And basic IR optimization added in:
rL338218
rL340022
...so these are expected to produce asm output that's equal or better to the multi-instruction
alternatives using primitive C/IR ops.
In the motivating loop example from PR37387:
https://bugs.llvm.org/show_bug.cgi?id=37387#c7
...we get the expected 'rolq' x86 instructions if we substitute the rotate builtin into the source.
Differential Revision: https://reviews.llvm.org/D50924
llvm-svn: 340135
|
|
|
|
|
|
|
|
| |
We were basically assuming only one operand of the compare could be an ADD node and using that to swap operands. But we can have a normal add followed by a saturing add.
This rewrites the canonicalization to just be based on the condition code.
llvm-svn: 340134
|
|
|
|
|
|
| |
We are unable to handle a normal add followed by a saturing add with certain operand orders on the icmp.
llvm-svn: 340133
|
|
|
|
|
|
| |
This passes now.
llvm-svn: 340132
|
|
|
|
|
|
|
|
|
| |
Improving readability, removing redundant contents.
Reviewers: hiraditya
Differential Revision: https://reviews.llvm.org/D50686
llvm-svn: 340131
|
|
|
|
|
|
|
|
| |
matching.
isEqualTo is more useful for floating point. operator== is sufficient for integer.
llvm-svn: 340130
|
|
|
|
|
|
| |
While there remove some trailing whitespace.
llvm-svn: 340129
|
|
|
|
|
|
|
|
| |
The code already support 128 and 256 and even knows to split 256 for AVX1. So we really just needed to stop looking for specific VTs and subtarget features and just look for legal VTs with i8/i16 elements.
While there, add some curly braces around outer if statement bodies that contain only another if. It makes all the closing curly braces look more regular.
llvm-svn: 340128
|
|
|
|
| |
llvm-svn: 340127
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A while back I submitted a patch to resolve backreferences
lazily, thinking this that it was not always possible to know
in advance what type you were looking at until you had completed
a full pass over the input, and therefore it would be impossible
to resolve backreferences eagerly.
This was mistaken though, and turned out to be an unrelated
problem. In fact, the reverse is true. You *must* resolve
backreferences eagerly. This is because certain types of nested
mangled symbols do not share a backreference context with their
parent symbol, and as such, if you try to resolve them lazily
their backreference context will have been lost by the time you
finish demangling the entire input. On the other hand, resolving
them eagerly appears to always work, and enables us to port
many more tests over.
llvm-svn: 340126
|
|
|
|
|
|
|
|
|
|
| |
space for common symbols.
Patch by Dmitry Sidorov. Thanks Dmitry!
Differential revision: https://reviews.llvm.org/D50240
llvm-svn: 340125
|
|
|
|
|
|
| |
Helps reduce cost of instrw collection
llvm-svn: 340124
|
|
|
|
|
|
| |
Helps reduce cost of instrw collection
llvm-svn: 340123
|
|
|
|
|
|
|
|
| |
Convert llvm.dbg.label(!label_metadata) to DBG_LABEL !label_metadata.
Differential Revision: https://reviews.llvm.org/D50622
llvm-svn: 340122
|
|
|
|
|
|
| |
on the unsigned test case.
llvm-svn: 340121
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I believe this restores the behavior we had before r339147.
Fixes PR38622.
Reviewers: RKSimon, chandlerc, spatel
Reviewed By: chandlerc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D50936
llvm-svn: 340120
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 73786631984289b3d601034b2bf4ba2b8f5845eb.
Revert r339961 since its causing debuginfo-tests to fail:
http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/48514/
rdar://problem/43449629
llvm-svn: 340119
|
|
|
|
|
|
|
| |
After this we should have the entire AVX-512 register set
mapping in place.
llvm-svn: 340118
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit a786521fa66c72edd308baff0c08961b6d964fb1.
Bots haven't caught up yet, but broke modules build with:
../tools/clang/include/clang/StaticAnalyzer/Checkers/MPIFunctionClassifier.h:18:10:
fatal error: cyclic dependency in module 'Clang_StaticAnalyzer_Core':
Clang_StaticAnalyzer_Core -> Clang_Analysis ->
Clang_StaticAnalyzer_Checkers -> Clang_StaticAnalyzer_Core
^
llvm-svn: 340117
|
|
|
|
| |
llvm-svn: 340116
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An emitted symbol has had its contents written and its memory protections
applied, but it is not automatically ready to execute.
Prior to ORC supporting concurrent compilation, the term "finalized" could be
interpreted two different (but effectively equivalent) ways: (1) The finalized
symbol's contents have been written and its memory protections applied, and (2)
the symbol is ready to run. Now that ORC supports concurrent compilation, sense
(1) no longer implies sense (2). We have already introduced a new term, 'ready',
to capture sense (2), so rename sense (1) to 'emitted' to avoid any lingering
confusion.
llvm-svn: 340115
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARCMigrator is using code from RetainCountChecker, which is a layering
violation (and it also does it badly, by using a different header, and
then relying on implementation being present in a header file).
This change splits up RetainSummaryManager into a separate library in
lib/Analysis, which can be used independently of a checker.
Differential Revision: https://reviews.llvm.org/D50934
llvm-svn: 340114
|
|
|
|
|
|
|
|
| |
Remove code for writing auxiliary symbols of type function definition
and begin function. These types of symbols are associated with
pre-CodeView debug info and we never emit them.
llvm-svn: 340113
|
|
|
|
|
|
| |
load and poor machines.
llvm-svn: 340112
|
|
|
|
|
|
|
|
|
|
| |
https://reviews.llvm.org/D48847#inline-448257
Ported legalization expansions for CTLZ/CTTZ from DAG to GISel.
Reviewed by rtereshin.
llvm-svn: 340111
|
|
|
|
| |
llvm-svn: 340110
|
|
|
|
|
|
| |
they are present in the ObjC type
llvm-svn: 340109
|
|
|
|
|
|
| |
Printing "unknown" is much more clear than an arbitrary large integer
llvm-svn: 340108
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Port GNU Objcopy -G/--keep-global-symbol(s).
This is slightly different than the already-implemented --globalize-symbol, which marks a symbol as global when copying. When --keep-global-symbol (alias -G) is used, *only* those symbols marked will stay global, and all other globals are demoted to local. (Also note that it doesn't *promote* a symbol to global). Additionally, there is a pluralized version of the flag --keep-global-symbols, which effectively applies --keep-global-symbol for every non-comment in a file.
Reviewers: jakehehrlich, jhenderson, alexshap
Reviewed By: jhenderson
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D50589
llvm-svn: 340105
|
|
|
|
| |
llvm-svn: 340104
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expression
Clang emits invalid protocol metadata when a @protocol expression is used with a
forward-declared protocol. The protocol metadata is missing protocol conformance
list of the protocol since we don't have access to the definition of it in the
compiled translation unit. The linker then might end up picking the invalid
metadata when linking which will lead to incorrect runtime protocol conformance
checks.
This commit makes sure that Clang fails to compile code that uses a @protocol
expression with a forward-declared protocol. This ensures that Clang does not
emit invalid protocol metadata. I added an extra assert in CodeGen to ensure
that this kind of issue won't happen in other places.
rdar://32787811
Differential Revision: https://reviews.llvm.org/D49462
llvm-svn: 340102
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There isn't anything inherently wrong with returning a label from a
statement expression. In practice, the Linux kernel uses this pattern to
materialize PCs.
Fixes PR38569
Reviewers: niravd, rsmith, nickdesaulniers
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50805
llvm-svn: 340101
|
|
|
|
| |
llvm-svn: 340100
|
|
|
|
| |
llvm-svn: 340099
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D50879
llvm-svn: 340098
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D50872
llvm-svn: 340097
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D50869
llvm-svn: 340096
|