| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
Originally committed in r237975, GCC 4.7 gave a compilation error
regarding "looser throw specification" though it seemed to be pointing
to a virtual defaulted dtor in a base class and an override defaulted
dtor in a derived class - so I'm not quite sure why/how they could end
up with different throw specifications. To simplify and reduce the risk
of this, I've just removed the pointless override in the derived class,
the base class's should be sufficient. *fingers crossed*
llvm-svn: 239088
|
| |
|
|
|
|
|
|
|
|
| |
Now that we can look at users, we can trivially do this: when we would
have otherwise disabled GlobalMerge (currently -O<3), we can just run
it for minsize functions, as it's usually a codesize win.
Differential Revision: http://reviews.llvm.org/D10054
llvm-svn: 239087
|
| |
|
|
| |
llvm-svn: 239085
|
| |
|
|
|
|
|
|
|
|
| |
Fix the FIXME and remove this old as(1) compat option. It was useful for
bringup of the integrated assembler to diff object files, but now it's
just causing more relocations than strictly necessary to be generated.
rdar://21201804
llvm-svn: 239084
|
| |
|
|
|
|
|
|
|
|
|
| |
I made a few changes here in a couple of commits - breaking them out
into smaller ones in case I hit the GCC oddities again.
I'm still not /entirely/ sure what the issues were, so apologies if any
of these experiments break things again. Feel free to revert
immediately.
llvm-svn: 239083
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
With this patch, NVPTXLowerKernelArgs converts a kernel pointer argument to a
pointer in the global address space. This change, along with
NVPTXFavorNonGenericAddrSpaces, allows the NVPTX backend to emit ld.global.*
and st.global.* for accessing kernel pointer arguments.
Minor changes:
1. refactor: extract function convertToPointerInAddrSpace
2. fix a bug in the test case in bug21465.ll
Test Plan: lower-kernel-ptr-arg.ll
Reviewers: eliben, meheff, jholewinski
Reviewed By: jholewinski
Subscribers: wengxt, jholewinski, llvm-commits
Differential Revision: http://reviews.llvm.org/D10154
llvm-svn: 239082
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Properly report the error in segment load commands from MachOObjectFile
constructor instead of crashing the program.
Adjust the test case accordingly.
Test Plan: regression test suite
Reviewers: rafael, filcab
Subscribers: llvm-commits
llvm-svn: 239081
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently all load commands are parsed in MachOObjectFile constructor.
If the next load command cannot be parsed, or if command size is too
small, properly report it through the error code and fail to construct
the object, instead of crashing the program.
Test Plan: regression test suite
Reviewers: rafael, filcab
Subscribers: llvm-commits
llvm-svn: 239080
|
| |
|
|
| |
llvm-svn: 239079
|
| |
|
|
|
|
|
|
|
|
|
| |
Summary: Instead, properly report this error from MachOObjectFile constructor.
Test Plan: regression test suite
Reviewers: rafael
Subscribers: llvm-commits
llvm-svn: 239078
|
| |
|
|
| |
llvm-svn: 239077
|
| |
|
|
|
|
| |
Enabling Ninja Job Pools needs to be dependent on the CMAKE_MAKE_PROGRAM not the CMAKE_GENERATOR. There are generators (like "Sublime Text 2 - Ninja") that also generate ninja build files. Basing of the CMAKE_MAKE_PROGRAM is the best future-proof way to handle this.
llvm-svn: 239076
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Avoid parsing object file each time MachOObjectFile::getHeader() is
called. Instead, cache the header in MachOObjectFile constructor, where
it's parsed anyway. In future, we must avoid constructing the object
at all if the header can't be parsed.
Test Plan: regression test suite.
Reviewers: rafael
Subscribers: llvm-commits
llvm-svn: 239075
|
| |
|
|
| |
llvm-svn: 239074
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
-march=bpf -> host endian
-march=bpf_le -> little endian
-match=bpf_be -> big endian
Test Plan:
v1 was tested by IBM s390 guys and appears to be working there.
It bit rots too fast here.
Reviewers: chandlerc, tstellarAMD
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10177
llvm-svn: 239071
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Method 'visitBUILD_VECTOR' in the DAGCombiner knows how to combine a
build_vector of a bunch of extract_vector_elt nodes and constant zero nodes
into a shuffle blend with a zero vector.
However, method 'visitBUILD_VECTOR' forgot that a floating point
build_vector may contain negative zero as well as positive zero.
Example:
define <2 x double> @example(<2 x double> %A) {
entry:
%0 = extractelement <2 x double> %A, i32 0
%1 = insertelement <2 x double> undef, double %0, i32 0
%2 = insertelement <2 x double> %1, double -0.0, i32 1
ret <2 x double> %2
}
Before this patch, llc (with -mattr=+sse4.1) wrongly generated
movq %xmm0, %xmm0 # xmm0 = xmm0[0],zero
So, the sign bit of the negative zero was effectively lost.
This patch fixes the problem by adding explicit checks for positive zero.
With this patch, llc produces the following code for the example above:
movhpd .LCPI0_0(%rip), %xmm0
where .LCPI0_0 referes to a 'double -0'.
llvm-svn: 239070
|
| |
|
|
|
|
|
|
|
|
| |
The current check never passes, because CMAKE_MAKE_PROGRAM, at least on Linux,
includes the full path to the "ninja" binary; this effectively disables
compile/link jobs pools.
Use CMAKE_GENERATOR STREQUAL "Ninja" as a more reliable check.
llvm-svn: 239069
|
| |
|
|
| |
llvm-svn: 239068
|
| |
|
|
|
|
|
|
| |
* If the input file is missing;
* If the type of input object file can't be recognized;
* If the object file can't be parsed correctly.
llvm-svn: 239065
|
| |
|
|
|
|
| |
Add a unit test.
llvm-svn: 239062
|
| |
|
|
|
|
| |
Fix trailing whitespace.
llvm-svn: 239058
|
| |
|
|
| |
llvm-svn: 239056
|
| |
|
|
|
|
|
|
|
|
|
| |
Now that we sometimes know the address space, this can
theoretically do a better job.
This needs better test coverage, but this mostly depends on
first updating the loop optimizatiosn to provide the address
space.
llvm-svn: 239053
|
| |
|
|
|
|
| |
Use -1 as the address space if it can't be determined.
llvm-svn: 239052
|
| |
|
|
|
|
|
| |
No test because I don't know of a target that makes use
of address spaces and indexed load / store.
llvm-svn: 239051
|
| |
|
|
|
|
|
| |
Mostly argument loads were producing broken zextloads
from an FP type.
llvm-svn: 239049
|
| |
|
|
|
|
|
|
| |
When checking (High - Low + 1).sle(BitWidth), BitWidth would be truncated
to the size of the left-hand side. In the case of this PR, the left-hand
side was i4, so BitWidth=64 got truncated to 0 and the assert failed.
llvm-svn: 239048
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Section symbols exist as an optimization: instead of having multiple relocations
point to different symbols, many of them can point to a single section symbol.
When that optimization is unused, a section symbol is also unused and adds no
extra information to the object file.
This saves a bit of space on the object files and makes the output of
llvm-objdump -t easier to read and consequently some tests get quite a bit
simpler.
llvm-svn: 239045
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of CMake or non-ninja generators.
Summary: I've gotten feedback from users on CMake 2.8 that the compile and link pool options were not working. This is expected so I'm adding a warning so we can report invalid configurations to users.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10193
llvm-svn: 239044
|
| |
|
|
| |
llvm-svn: 239043
|
| |
|
|
| |
llvm-svn: 239042
|
| |
|
|
| |
llvm-svn: 239041
|
| |
|
|
|
|
| |
Less code, clearer and more efficient. No functionality change intended.
llvm-svn: 239040
|
| |
|
|
|
|
|
| |
We already handled a section with no symbols, extend that to also handle a
section with symbols that don't include the section start.
llvm-svn: 239039
|
| |
|
|
|
|
|
|
|
| |
If the compare in a select pattern has another use then it can't be removed, so we'd just
be creating repeated code if we created a min/max node.
Spotted by Matt Arsenault!
llvm-svn: 239037
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
create*AsmInfo(). NFC.
Summary:
This is the first of several patches to eliminate StringRef forms of GNU
triples from the internals of LLVM. After this is complete, GNU triples
will be replaced by a more authoratitive representation in the form of
an LLVM TargetTuple.
Reviewers: rengolin
Reviewed By: rengolin
Subscribers: ted, llvm-commits, rengolin, jholewinski
Differential Revision: http://reviews.llvm.org/D10236
llvm-svn: 239036
|
| |
|
|
| |
llvm-svn: 239035
|
| |
|
|
|
|
|
|
|
| |
Removed the redundant "llvm::" from class names in InstrProfiling.cpp
clang-format is ran on the changes.
Patch from Betul Buyukkurt.
llvm-svn: 239034
|
| |
|
|
|
|
| |
Patch by deadalnix (Amaury SECHET).
llvm-svn: 239029
|
| |
|
|
|
|
| |
I re-generated it after all AVX-512 shuffle optimizations.
llvm-svn: 239026
|
| |
|
|
| |
llvm-svn: 239023
|
| |
|
|
| |
llvm-svn: 239022
|
| |
|
|
|
|
| |
Name to reduce memory usage.
llvm-svn: 239021
|
| |
|
|
| |
llvm-svn: 239019
|
| |
|
|
|
|
|
|
| |
We don't need to go through LSR to trigger this bug. Instead,
hand-craft a tricky GEP and get the constant folder to hack on it when
parsing the IR.
llvm-svn: 239017
|
| |
|
|
|
|
|
| |
Added all forms of VPERMPS/PD instrcuctions.
Added encoding tests.
llvm-svn: 239016
|
| |
|
|
|
|
|
|
|
| |
We neglected to check if the first index made the GEP ineligible for
'inbounds'.
This fixes PR23753.
llvm-svn: 239015
|
| |
|
|
| |
llvm-svn: 239014
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fix is just that getOther had not been updated for packing the st_other
values in fewer bits and could return spurious values:
- unsigned Other = (getFlags() & (0x3f << ELF_STO_Shift)) >> ELF_STO_Shift;
+ unsigned Other = (getFlags() & (0x7 << ELF_STO_Shift)) >> ELF_STO_Shift;
Original message:
Pack the MCSymbolELF bit fields into MCSymbol's Flags.
This reduces MCSymolfELF from 64 bytes to 56 bytes on x86_64.
While at it, also make getOther/setOther easier to use by accepting unshifted
STO_* values.
llvm-svn: 239012
|
| |
|
|
| |
llvm-svn: 239011
|