| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 310804
|
| |
|
|
|
|
| |
C++17 and before.
llvm-svn: 310803
|
| |
|
|
| |
llvm-svn: 310802
|
| |
|
|
| |
llvm-svn: 310801
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
make check-profile:
Failing Tests (2):
Profile-i386 :: instrprof-dlopen.test
Profile-x86_64 :: instrprof-dlopen.test
Expected Passes : 64
Unsupported Tests : 42
Unexpected Failures: 2
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, kcc, filcab, fjricci
Reviewed By: vitalybuka
Subscribers: vsk, llvm-commits, srhines, mgorny, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36603
llvm-svn: 310800
|
| |
|
|
| |
llvm-svn: 310799
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D36364
llvm-svn: 310798
|
| |
|
|
|
|
|
|
|
|
|
|
| |
environments
This allows using semicolons for bundling up more than one
statement per line. This is used within the mingw-w64 project in some
assembly files that contain code for multiple architectures.
Differential Revision: https://reviews.llvm.org/D36366
llvm-svn: 310797
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was mistakenly added to that list in D23560 (committed in rL285712). RISCV
is an experimental backend and should never have been in that list, I
mistakenly interpreted LLVM_ALL_TARGETS as a list of all targets rather than
targets to build by default. Unfortunately, because of this the RISCV backend
has been building by default when it shouldn't be.
This commet adds a description comment, which should help to avoid such
mistakes in the future.
See my message to llvm-dev for more information and analysis
<http://lists.llvm.org/pipermail/llvm-dev/2017-August/116347.html>.
Differential Revision: https://reviews.llvm.org/D36538
llvm-svn: 310796
|
| |
|
|
| |
llvm-svn: 310795
|
| |
|
|
|
|
|
|
|
|
|
|
| |
answers for extracting 128-bits from a 512-bit vector and for mask registers.
Previously it would not return true for extracting either of the upper quarters of a 512-bit registers.
For mask registers we support extracting anything from index 0. And otherwise we only support extracting the upper half of a register.
Differential Revision: https://reviews.llvm.org/D36638
llvm-svn: 310794
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Without the SrcVT its hard to know what is really being asked for. For example if your target has 128, 256, and 512 bit vectors. Maybe extracting 128 from 256 is cheap, but maybe extracting 128 from 512 is not.
For x86 we do support extracting a quarter of a 512-bit register. But for i1 vectors we don't have isel patterns for extracting arbitrary pieces. So we need this to have a correct implementation of isExtractSubvectorCheap for mask vectors.
Reviewers: RKSimon, zvi, efriedma
Reviewed By: RKSimon
Subscribers: aemerson, javed.absar, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D36649
llvm-svn: 310793
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
information
This is a continuation patch for commit r307529 which completely replaces the scheduling information for the SandyBridge architecture target by modifying the file X86SchedSandyBridge.td located under the X86 Target (see also https://reviews.llvm.org/D35019).
In this patch we added the scheduling information of additional SNB instructions that were missing from the patch commit r307529, fixed the scheduling of several resource groups that include only port0 instead of port05 (i.e., port0 OR port5) and fixed several incorrect instructions' scheduling in the r307529 commit.
The patch also includes the X87 instructions which were missing in previous patch commit r307529 as reported in bugzilla bug 34080.
Reviewers: zvi, RKSimon, chandlerc, igorb, m_zuckerman, craig.topper, aymanmus, dim
Differential Revision: https://reviews.llvm.org/D36388
llvm-svn: 310792
|
| |
|
|
|
|
| |
An existing test should have covered this but a typo caused it to fail. I've kept both as the codegen for the typo case needs addressing as well.
llvm-svn: 310791
|
| |
|
|
|
|
|
|
| |
instructions.
And fails to select TBM instructions at all.
llvm-svn: 310790
|
| |
|
|
|
|
|
|
|
| |
K0 isn't expected as a write-mask, so provide a detailed error here, instead of the more generic one (invalid op for insn)
Conforms with gas
Differential Revision: https://reviews.llvm.org/D36570
llvm-svn: 310789
|
| |
|
|
| |
llvm-svn: 310788
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add an X86 combine for TESTM when one of the operands is a BUILD_VECTOR(0,0,...).
TESTM op0, BUILD_VECTOR(0,0,...) -> BUILD_VECTOR(0,0,...)
TESTM BUILD_VECTOR(0,0,...), op1 -> BUILD_VECTOR(0,0,...)
Differential Revision:
https://reviews.llvm.org/D36536
llvm-svn: 310787
|
| |
|
|
|
|
| |
The combines here shouldn't be done for mask vectors, but it wasn't clear anything was preventing that.
llvm-svn: 310786
|
| |
|
|
| |
llvm-svn: 310785
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
correct type so we don't crash if we use a memory instruction
Summary:
Previously we were creating the flag result with MVT::Other which is interpretted as a Chain node. If we used a memory form of the instruction we would end up with a copyToReg that consumed the chain result of the adcx instruction instead of the flag result.
Pretty sure we should be using MVT::i32 here, that's what we do other places we create these node types.
We should probably consider this for 5.0 as well.
Reviewers: RKSimon, zvi, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D36645
llvm-svn: 310784
|
| |
|
|
| |
llvm-svn: 310783
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If all the operands of a BUILD_VECTOR extract elements from same vector then split the vector efficiently based on the maximum vector access index.
Reapplied with fix to only work with simple value types.
Committed on behalf of @jbhateja (Jatin Bhateja)
Differential Revision: https://reviews.llvm.org/D35788
llvm-svn: 310782
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
isThumb returns true for Thumb triples (little and big endian), isARM
returns true for ARM triples (little and big endian).
There are a few more checks using arm/thumb that are not covered by
those functions, e.g. that the architecture is either ARM or Thumb
(little endian) or ARM/Thumb little endian only.
Reviewers: javed.absar, rengolin, kristof.beyls, t.p.northover
Reviewed By: rengolin
Subscribers: llvm-commits, aemerson
Differential Revision: https://reviews.llvm.org/D34682
llvm-svn: 310781
|
| |
|
|
|
|
| |
Gives us a much better idea of what is going on than just relying on a few checks.
llvm-svn: 310780
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR34037)
nsw, nuw, and exact carry implicit assumptions about their operands, so we need
to clear those after trivializing a value. We decided there was no danger for
llvm.assume or metadata, so there's just a comment about that.
This fixes miscompiles as shown in:
https://bugs.llvm.org/show_bug.cgi?id=33695
https://bugs.llvm.org/show_bug.cgi?id=34037
Differential Revision: https://reviews.llvm.org/D36592
llvm-svn: 310779
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D34824
llvm-svn: 310778
|
| |
|
|
| |
llvm-svn: 310777
|
| |
|
|
|
|
|
|
|
|
|
| |
the class becoming complete and its inline methods being parsed.
This replaces the hack of using the "late parsed template" flag to track member
functions with bodies we've not parsed yet; instead we now use the "will have
body" flag, which carries the desired implication that the function declaration
*is* a definition, and that we've just not parsed its body yet.
llvm-svn: 310776
|
| |
|
|
|
|
|
| |
This reverts commit r310605. Richard pointed out a better way to achieve
this, which I'll post a patch for soon.
llvm-svn: 310775
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add a Dockerfile for clang-proto-fuzzer
Reviewers: morehouse, vitalybuka
Reviewed By: morehouse
Subscribers: hintonda, cfe-commits
Differential Revision: https://reviews.llvm.org/D36635
llvm-svn: 310774
|
| |
|
|
|
|
|
|
|
|
|
| |
`external_weak` global
An `external_weak` global may be intended to resolve as a null pointer if it's
not defined, so it doesn't make sense to use a copy relocation for it.
Differential Revision: https://reviews.llvm.org/D36604
llvm-svn: 310773
|
| |
|
|
|
|
|
|
| |
configurations.
Differential revision: https://reviews.llvm.org/D29660
llvm-svn: 310772
|
| |
|
|
|
|
| |
(fprofile-instr-generate), Linux-only
llvm-svn: 310771
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As noted in the test comment, instcombine now produces the masked
shift value even when it's not included in the source, so we should
handle this.
Although the AMD/Intel docs don't say it explicitly, over-rotating
the narrow ops produces the same results. An existence proof that
this works as expected on all x86 comes from gcc 4.9 or later:
https://godbolt.org/g/K6rc1A
llvm-svn: 310770
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is to support Android where libc++abi is part of libc++.
Reviewers: srhines, EricWF
Subscribers: dberris, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D36640
llvm-svn: 310769
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The stack alignment depends on the ABI (16 bytes for N32 and N64 and 8
bytes for O32), not the CPU type.
Reviewers: sdardis
Reviewed By: sdardis
Subscribers: atanasyan, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D36326
llvm-svn: 310768
|
| |
|
|
| |
llvm-svn: 310767
|
| |
|
|
|
|
| |
warnings; other minor fixes (NFC).
llvm-svn: 310766
|
| |
|
|
|
|
|
|
| |
offloading test file. This should prevent further errors
with the sanitizer.
Diff: D29660
llvm-svn: 310765
|
| |
|
|
|
|
|
| |
These were pending in a separate patch but I forgot to squash them
before comitting, and this one didn't go through.
llvm-svn: 310764
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Updating remark API to newer OptimizationDiagnosticInfo API. This
allows remarks to show up in diagnostic yaml file, and enables use
of opt-viewer tool.
Hotness information for remarks (L505 and L751) do not display hotness
information, most likely due to profile information not being
propagated yet. Unsure if this is the desired outcome.
Patch by Tarun Rajendran.
Differential Revision: https://reviews.llvm.org/D36127
llvm-svn: 310763
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously we would use these instructions if sse was disabled and fastmath was enabled.
As mentioned in D28335, this is a bad idea.
Reviewers: efriedma, scanon, DavidKreitzer
Reviewed By: DavidKreitzer
Subscribers: zvi, llvm-commits
Differential Revision: https://reviews.llvm.org/D36344
llvm-svn: 310762
|
| |
|
|
|
|
|
|
|
|
| |
This improves readability and (theoretically) improves portability,
as _Ugly names are reserved.
This performs additional de-uglification, so all of these tests
follow the example of iterator.traits/empty.pass.cpp.
llvm-svn: 310761
|
| |
|
|
|
|
|
| |
This improves readability and (theoretically) improves portability,
as __ugly names are reserved.
llvm-svn: 310760
|
| |
|
|
|
|
|
| |
This improves readability and (theoretically) improves portability,
as __ugly names are reserved.
llvm-svn: 310759
|
| |
|
|
|
|
|
| |
This improves readability and (theoretically) improves portability,
as _Ugly names are reserved.
llvm-svn: 310758
|
| |
|
|
| |
llvm-svn: 310757
|
| |
|
|
|
|
|
|
|
|
| |
When the access to a weak symbol is not a call, the access has to be
able to produce the value 0 at runtime.
We were sometimes producing code sequences where that was not possible
if the code was leaded more than 4g away from 0.
llvm-svn: 310756
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The linker module contains a symbol of type S_COMPILE3 which
contains various information about the compiler and linker used
to create the PDB, such as the name of the linker, the target
machine, and the linker version. Interestingly, if we set the
version string to 0.0.0.0, then when trying to view local
variables WinDbg emits an error that private symbols are not
present. By setting this to a valid MSVC linker version string,
local variables can display.
As such, even though it is not representative of LLVM's version
information, we need this for compatibility.
llvm-svn: 310755
|