| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
We used to list registers that were not in the AVX space. In other
words, we were pushing registers that the ISA cannot encode
(YMM16-YMM31).
This is part of llvm.org/PR27481.
llvm-svn: 268983
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20077
llvm-svn: 268980
|
| |
|
|
| |
llvm-svn: 268979
|
| |
|
|
| |
llvm-svn: 268975
|
| |
|
|
|
|
| |
pass manager
llvm-svn: 268974
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is similar to r268953, but for floating point and vector register
classes.
Explanations:
The setting of the inline asm constraints was implicitly relying on the
order of the register classes in the file generated by tablegen.
Since, we do not have any control on that order, make sure we do not
depend on it anymore.
llvm-svn: 268973
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As discussed on PR24888, until SSE42 we don't have access to PCMPGTQ for v2i64 comparisons, but the cost models don't reflect this, resulting in over-optimistic vectorizaton.
This patch adds SSE2 'base level' costs that match what a typical target is capable of and only reduces the v2i64 costs at SSE42.
Technically SSE41 provides a PCMPEQQ v2i64 equality test, but as getCmpSelInstrCost doesn't give us a way to discriminate between comparison test types we can't easily make use of this, otherwise we could split the cost of integer equality and greater-than tests to give better costings of each.
Differential Revision: http://reviews.llvm.org/D20057
llvm-svn: 268972
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IR instrumentation generates a COMDAT symbol __llvm_profile_raw_version to
overwrite the same symbol in profile run-time to distinguish IR profiles from
Clang generated profiles. In MACHO, LinkOnceODR linkage is used due to the
lack of COMDAT support.
But LinkOnceODR linkage might have .weak_def_can_be_hidden assembly directive,
while the weak variable in run-time has a .weak_definition directive. Linker
will not merge these two symbols even they have the same name. The end result
is IR profiles are not properly flagged in MACHO.
This patch changes the linkage for __llvm_profile_raw_version in each module to
LinkOnceAny so that it has same .weak_definition directive as in the run-time.
Differential Revision: http://reviews.llvm.org/D20078
llvm-svn: 268969
|
| |
|
|
|
|
| |
libFuzzer+ubsan
llvm-svn: 268968
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes http://llvm.org/PR27646 on AArch64.
There are three issues here:
- The GR save area is 7 words in size, instead of 8. This is not enough
if none of the fixed arguments is passed in GRs (they're all floats or
aggregates).
- The first argument is ignored (which counteracts the above if it's passed
in GR).
- Like x86_64, fixed arguments landing in the overflow area are wrongly
counted towards the overflow offset.
Differential Revision: http://reviews.llvm.org/D20023
llvm-svn: 268967
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
allow the transformation to strip invalid debug info.
This patch separates the Verifier into an analysis and a transformation
pass, with the transformation pass optionally stripping malformed
debug info.
The problem I'm trying to solve with this sequence of patches is that
historically we've done a really bad job at verifying debug info. We want
to be able to make the verifier stricter without having to worry about
breaking bitcode compatibility with existing producers. For example, we
don't necessarily want IR produced by an older version of clang to be
rejected by an LTO link just because of malformed debug info, and rather
provide an option to strip it. Note that merely outdated (but well-formed)
debug info would continue to be auto-upgraded in this scenario.
http://reviews.llvm.org/D19988
rdar://problem/25818489
This reapplies r268937 without modifications.
llvm-svn: 268966
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces a new option -lto-strip-invalid-debug-info, which
drops malformed debug info from the input.
The problem I'm trying to solve with this sequence of patches is that
historically we've done a really bad job at verifying debug info. We want
to be able to make the verifier stricter without having to worry about
breaking bitcode compatibility with existing producers. For example, we
don't necessarily want IR produced by an older version of clang to be
rejected by an LTO link just because of malformed debug info, and rather
provide an option to strip it. Note that merely outdated (but well-formed)
debug info would continue to be auto-upgraded in this scenario.
rdar://problem/25818489
http://reviews.llvm.org/D19987
This reapplies 268936 with a test case fix for Linux (-exported-symbol foo)
llvm-svn: 268965
|
| |
|
|
|
|
|
| |
The only 64-bit register in that register class is RIP and it will not
get spilled in the current ABIs.
llvm-svn: 268963
|
| |
|
|
| |
llvm-svn: 268961
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20036
llvm-svn: 268960
|
| |
|
|
| |
llvm-svn: 268959
|
| |
|
|
| |
llvm-svn: 268958
|
| |
|
|
| |
llvm-svn: 268957
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reapplies commit r268796, with a fix for the setting of the inline asm
constraints. I.e., "mark" LOW32_ADDR_ACCESS_RBP as a GR variant, so that the
regular processing of the GR operands (setting of the subregisters) happens.
Original commit log:
[X86] Add a new LOW32_ADDR_ACCESS_RBP register class.
ABIs like NaCl uses 32-bit addresses but have 64-bit frame.
The new register class reflects those constraints when choosing a
register class for a address access.
llvm-svn: 268955
|
| |
|
|
|
|
| |
changes.
llvm-svn: 268954
|
| |
|
|
|
|
|
|
|
| |
The setting of the inline asm constraints was implicitly relying on the
order of the register classes in the file generated by tablegen.
Since, we do not have any control on that order, make sure we do not
depend on it anymore.
llvm-svn: 268953
|
| |
|
|
|
|
|
|
|
| |
This patch corresponds to review:
http://reviews.llvm.org/D19683
Simply adds the bits for being able to specify -mcpu=pwr9 to the back end.
llvm-svn: 268950
|
| |
|
|
| |
llvm-svn: 268949
|
| |
|
|
| |
llvm-svn: 268948
|
| |
|
|
| |
llvm-svn: 268946
|
| |
|
|
| |
llvm-svn: 268944
|
| |
|
|
| |
llvm-svn: 268943
|
| |
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20026
Reviewed By: rnk
llvm-svn: 268942
|
| |
|
|
|
|
|
| |
Reviewed By: amccarth
Differential Revision: http://reviews.llvm.org/D20038
llvm-svn: 268941
|
| |
|
|
|
|
|
|
| |
input."
This reverts commit 268936 while investigating buildbot breakage.
llvm-svn: 268940
|
| |
|
|
|
|
| |
This reverts commit 268937 while investigating build bot breakage.
llvm-svn: 268939
|
| |
|
|
|
|
| |
r268896.
llvm-svn: 268938
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
allow the transformation to strip invalid debug info.
This patch separates the Verifier into an analysis and a transformation
pass, with the transformation pass optionally stripping malformed
debug info.
The problem I'm trying to solve with this sequence of patches is that
historically we've done a really bad job at verifying debug info. We want
to be able to make the verifier stricter without having to worry about
breaking bitcode compatibility with existing producers. For example, we
don't necessarily want IR produced by an older version of clang to be
rejected by an LTO link just because of malformed debug info, and rather
provide an option to strip it. Note that merely outdated (but well-formed)
debug info would continue to be auto-upgraded in this scenario.
http://reviews.llvm.org/D19988
rdar://problem/25818489
llvm-svn: 268937
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces a new option -lto-strip-invalid-debug-info, which
drops malformed debug info from the input.
The problem I'm trying to solve with this sequence of patches is that
historically we've done a really bad job at verifying debug info. We want
to be able to make the verifier stricter without having to worry about
breaking bitcode compatibility with existing producers. For example, we
don't necessarily want IR produced by an older version of clang to be
rejected by an LTO link just because of malformed debug info, and rather
provide an option to strip it. Note that merely outdated (but well-formed)
debug info would continue to be auto-upgraded in this scenario.
rdar://problem/25818489
http://reviews.llvm.org/D19987
llvm-svn: 268936
|
| |
|
|
|
|
|
| |
It's possible that we have branch weights with 0 values.
In that case, don't try to create an impossible BranchProbability.
llvm-svn: 268935
|
| |
|
|
|
|
| |
The post dominator tree does not have a root node in this case.
llvm-svn: 268933
|
| |
|
|
|
|
|
|
|
|
| |
After looking at D19087 again, it occurred to me that we can do better. If we consolidate
the valueHasExactlyOneBitSet() transforms, we won't incur extra overhead from calling it a
2nd time, and we can shrink SimplifySetCC() a bit. No functional change intended.
Differential Revision: http://reviews.llvm.org/D20050
llvm-svn: 268932
|
| |
|
|
| |
llvm-svn: 268931
|
| |
|
|
| |
llvm-svn: 268930
|
| |
|
|
| |
llvm-svn: 268929
|
| |
|
|
|
|
| |
by MSVC
llvm-svn: 268928
|
| |
|
|
|
|
| |
by MSVC.
llvm-svn: 268927
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The BinaryHolder would query the archive member MemoryBuffer name
to check if the current open archive also contains the next requested
objectfile. This comparison was using a StringRef to a temporary
buffer. It only happened with fat archives. This commit adds long-lived
storage along with the MemoryBuffers for the fat archive filename.
The added test would fail during an ASAN build without the fix.
llvm-svn: 268924
|
| |
|
|
| |
llvm-svn: 268922
|
| |
|
|
|
|
| |
When deciding if a vector calculation can be done in a smaller bitwidth, use sign bit information from ValueTracking to add more information and allow more truncations.
llvm-svn: 268921
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, it returned the GPR16MMRegClass for all instructions which was
incorrect for instructions like lwsp/lwgp and unnecesarily restricted the
permitted registers for instructions like lw32.
This fixes quite a few of the -verify-machineinstrs errors reported in PR27458.
I've only added -verify-machineinstrs to one test in this change since I
understand there is a plan to enable the verifier by default.
Reviewers: hvarga, zbuljan, zoran.jovanovic, sdardis
Subscribers: dsanders, llvm-commits, sdardis
Differential Revision: http://reviews.llvm.org/D19873
llvm-svn: 268918
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
updated.
When updating an existing archive, llvm-ar opens the old archive into a
`MemoryBuffer`, does its thing, and writes the results to a temporary
file. That file is then renamed to the original archive filename, thus
replacing it with the updated contents. However, on Windows at least,
what would happen is that the `MemoryBuffer` for the old archive would
actually be an mmap'ed view of the file, so when it came time to do the
rename via Win32's `ReplaceFile`, it would succeed but would be unable
to fully replace the file since there would still be a handle open on
it; instead, the old version got renamed to a random temporary name and
left behind.
Patch by Cameron!
llvm-svn: 268916
|
| |
|
|
|
|
|
|
| |
shuffle comments
This came up in discussion on D19198
llvm-svn: 268915
|
| |
|
|
| |
llvm-svn: 268913
|
| |
|
|
|
|
|
|
|
| |
This patch fixes register alignment for long double type in
soft float mode. Before this patch alignment was 8 and this
patch changes it to 4.
Differential Revision: http://reviews.llvm.org/D18034
llvm-svn: 268909
|