| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
| |
CFI emits jump slots for indirect functions as a byte array
constant, and declares function-typed aliases to these constants.
This change fixes AsmPrinter to emit these aliases as function
symbols and not data symbols.
llvm-svn: 254674
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
multiple registers
Currently in LLVM's cost model, a vectorized arithmetic instruction will have
high cost if its type is split into multiple registers. However, this
punishment is too heavy and unnecessary. The overhead of the split should not
be on arithmetic instructions but instructions that implement the split. Note
that during vectorization we have calculated the register pressure, and we
only choose proper interleaving factor (and also vectorization factor) so
that we don't use more registers than the maximum number.
Here is a very simple example: if a vadd has the cost 1, and if we double VF
so that we need two registers to perform it, then its cost will become 4 with
the current implementation, which will prevent us to use larger VF.
Differential revision: http://reviews.llvm.org/D15159
llvm-svn: 254671
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds support for an optional weight when merging profile data with the llvm-profdata tool.
Weights are specified by adding an option ':<weight>' suffix to the input file names.
Adding support for arbitrary weighting of input profile data allows for relative importance to be placed on the
input data from multiple training runs.
Both sampled and instrumented profiles are supported.
Reviewers: dnovillo, bogner, davidxl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14547
llvm-svn: 254669
|
| |
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D15216
llvm-svn: 254668
|
| |
|
|
| |
llvm-svn: 254667
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Code generation often exposes redundant physical register copies through
virtual registers such as:
%vreg = COPY %PHYSREG
...
%PHYSREG = COPY %vreg
There are cases where no intervening clobber of %PHYSREG occurs, and the
later copy could therefore be removed. In some cases this further allows
us to remove the initial copy.
This patch contains a motivating example which comes from the x86 build
of Chrome, specifically cc::ResourceProvider::UnlockForRead uses
libstdc++'s implementation of hash_map. That example has two tests live
at the same time, and after machine sinking LLVM has confused itself
enough and things spilling EFLAGS is a great idea even though it's
never restored and the comparison results are both live.
Before this patch we have:
DEC32m %RIP, 1, %noreg, <ga:@L>, %noreg, %EFLAGS<imp-def>
%vreg1<def> = COPY %EFLAGS; GR64:%vreg1
%EFLAGS<def> = COPY %vreg1; GR64:%vreg1
JNE_1 <BB#1>, %EFLAGS<imp-use>
Both copies are useless. This patch tries to eliminate the later copy in
a generic manner.
dec is especially confusing to LLVM when compared with sub.
I wrote this patch to treat all physical registers generically, but only
remove redundant copies of non-allocatable physical registers because
the allocatable ones caused issues (e.g. when calling conventions weren't
properly modeled) and should be handled later by the register allocator
anyways.
The following tests used to failed when the patch also replaced allocatable
registers:
CodeGen/X86/StackColoring.ll
CodeGen/X86/avx512-calling-conv.ll
CodeGen/X86/copy-propagation.ll
CodeGen/X86/inline-asm-fpstack.ll
CodeGen/X86/musttail-varargs.ll
CodeGen/X86/pop-stack-cleanup.ll
CodeGen/X86/preserve_mostcc64.ll
CodeGen/X86/tailcallstack64.ll
CodeGen/X86/this-return-64.ll
This happens because COPY has other special meaning for e.g. dependency
breakage and x87 FP stack.
Note that all other backends' tests pass.
Reviewers: qcolombet
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15157
llvm-svn: 254665
|
| |
|
|
|
|
|
| |
Use APFloat APIs here Rather than manually type-punning through
unions.
llvm-svn: 254664
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a block has no terminator instructions, getFirstTerminator() returns
end(), which can't be used in dominance checks. Check dominance for phi
operands separately.
Also, remove some bits from WebAssemblyRegStackify.cpp that were causing
trouble on the same testcase; they were left behind from an earlier
experiment.
Differential Revision: http://reviews.llvm.org/D15210
llvm-svn: 254662
|
| |
|
|
|
|
|
|
| |
This commit provoked "error C2593: 'operator <<' is ambiguous" on MSVC.
This reverts commit r254655.
llvm-svn: 254661
|
| |
|
|
|
|
| |
CMake calls to set_property with APPEND string need to have a leading space.
llvm-svn: 254659
|
| |
|
|
|
|
| |
This fixes a bug introduced in r254627, and another occurance of the same bug in this file.
llvm-svn: 254657
|
| |
|
|
|
|
|
|
| |
The compiler can take advantage of the allocation/deallocation
function's properties. We knew how to do this for Itanium but had no
support for MSVC-style functions.
llvm-svn: 254656
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows easier construction of print helpers. Example:
Printable PrintLaneMask(unsigned LaneMask) {
return Printable([LaneMask](raw_ostream &OS) {
OS << format("%08X", LaneMask);
});
}
// Usage:
OS << PrintLaneMask(Mask);
Differential Revision: http://reviews.llvm.org/D14348
llvm-svn: 254655
|
| |
|
|
| |
llvm-svn: 254654
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Almost all these changes are conditioned and only apply to the new
x86-64 f128 type configuration, which will be enabled in a follow up
patch. They are required together to make new f128 work. If there is
any error, we should fix or revert them as a whole.
These changes should have no impact to current configurations.
* Relax type legalization checks to accept new f128 type configuration,
whose TypeAction is TypeSoftenFloat, not TypeLegal, but also has
TLI.isTypeLegal true.
* Relax GetSoftenedFloat to return in some cases f128 type SDValue,
which is TLI.isTypeLegal but not "softened" to i128 node.
* Allow customized FABS, FNEG, FCOPYSIGN on new f128 type configuration,
to generate optimized bitwise operators for libm functions.
* Enhance related Lower* functions to handle f128 type.
* Enhance DAGTypeLegalizer::run, SoftenFloatResult, and related functions
to keep new f128 type in register, and convert f128 operators to library calls.
* Fix Combiner, Emitter, Legalizer routines that did not handle f128 type.
* Add ExpandConstant to handle i128 constants, ExpandNode
to handle ISD::Constant node.
* Add one more parameter to getCommonSubClass and firstCommonClass,
to guarantee that returned common sub class will contain the specified
simple value type.
This extra parameter is used by EmitCopyFromReg in InstrEmitter.cpp.
* Fix infinite loop in getTypeLegalizationCost when f128 is the value type.
* Fix printOperand to handle null operand.
* Enhance ISD::BITCAST node to handle f128 constant.
* Expand new f128 type for BR_CC, SELECT_CC, SELECT, SETCC nodes.
* Enhance X86AsmPrinter to emit f128 values in comments.
Differential Revision: http://reviews.llvm.org/D15134
llvm-svn: 254653
|
| |
|
|
|
|
| |
instruction encodings.
llvm-svn: 254652
|
| |
|
|
|
|
|
|
|
|
|
| |
DenseMap is most applicable when both keys and values are small.
In this case, the value violates that assumption, causing quite
significant memory overhead. A std::unordered_map is more appropriate
in this case (or at least fixed the memory problems I was seeing).
Differential Revision: http://reviews.llvm.org/D14910
llvm-svn: 254651
|
| |
|
|
|
|
|
|
|
|
| |
This provides interface to get and set maximum function counts to Module. This
would allow things like determination of function hotness. The actual setting
of this max function count will have to be done in the frontend.
Differential Revision: http://reviews.llvm.org/D15003
llvm-svn: 254647
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These ADJCALLSTACK markers don't generate code, but they keep dynamic
alloca code that calls chkstk out of the prologue.
This slightly pessimizes inalloca calls by preventing some register copy
coalescing, but I can live with that.
Reviewers: qcolombet
Subscribers: hans, llvm-commits
Differential Revision: http://reviews.llvm.org/D15200
llvm-svn: 254645
|
| |
|
|
|
|
| |
This prevents passthrough variables from having values.
llvm-svn: 254641
|
| |
|
|
| |
llvm-svn: 254640
|
| |
|
|
| |
llvm-svn: 254636
|
| |
|
|
| |
llvm-svn: 254631
|
| |
|
|
|
|
| |
Remove blank spaces at the end of comments
llvm-svn: 254630
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14996
llvm-svn: 254629
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This adds support for generating dSYM files and stripping debug info from executables and dylibs. It also supports passing -object_path_lto to the linker to generate dSYMs for LTO builds.
Reviewers: bogner, friss
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15133
llvm-svn: 254627
|
| |
|
|
|
|
| |
The indicies are one-based, not zero-based, per the spec.
llvm-svn: 254626
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix import from module with appending var, which cannot be imported. The
first fix is to remove an overly-aggressive error check.
The second fix is to deal with restructuring introduced to the module
linker yesterday in r254418 (actually, this fix was included already
in r254559, just added some additional cleanup).
Test by Mehdi Amini.
Reviewers: joker.eph, rafael
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D15156
llvm-svn: 254624
|
| |
|
|
| |
llvm-svn: 254623
|
| |
|
|
|
|
|
|
|
| |
In the case of a conditional branch without a preceding cmp we used to emit
a "and; cmp; b.eq/b.ne" sequence, use tbz/tbnz instead.
Differential Revision: http://reviews.llvm.org/D15122
llvm-svn: 254621
|
| |
|
|
| |
llvm-svn: 254620
|
| |
|
|
| |
llvm-svn: 254617
|
| |
|
|
|
|
| |
than doing it separately. This also ensures the integrated assembler path matches the assembly parser path.
llvm-svn: 254616
|
| |
|
|
|
|
| |
We now just return values and let ValueMap handle the map.
llvm-svn: 254615
|
| |
|
|
| |
llvm-svn: 254613
|
| |
|
|
| |
llvm-svn: 254610
|
| |
|
|
| |
llvm-svn: 254609
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Currently "<type> ptr <reg name>" treated as <reg name> in MS inline asm, ignoring the "<type> ptr" completely and possibly ignoring the intention of the user.
Fixed llvm to produce an error when encountering "<type> ptr <reg name>" operands.
For example: andpd xmm1,xmmword ptr xmm1 --> andpd xmm1, xmm1
though andpd has 2 possible matching formats - andpd xmm, xmm/m128
Patch by: ziv.izhar@intel.com
Differential Revision: http://reviews.llvm.org/D14607
llvm-svn: 254607
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15141
llvm-svn: 254598
|
| |
|
|
|
|
|
|
| |
According to x86 spec, fcomip and fucomip should be supported for Intel syntax.
Differential Revision: http://reviews.llvm.org/D15104
llvm-svn: 254595
|
| |
|
|
|
|
|
|
|
|
| |
destructor.
It is not enough to simply make the destructor virtual since there is a g++ 4.7
issue (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53613) that throws the
error "looser throw specifier for ... overridding ~SCEVPredicate() noexcept".
llvm-svn: 254592
|
| |
|
|
|
|
| |
MVT::SimpleValueType enum. Instead of assuming the types are sorted by size, scan the typeset arrays to find the smallest/largest type. NFC
llvm-svn: 254589
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is done only when targeting HSA.
Reviewers: arsenm
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D13807
llvm-svn: 254587
|
| |
|
|
|
|
|
|
|
|
| |
This works mostly fine but breaks some stage 1 builders when compiling
compiler-rt on i386. Revert for further investigation as I can't see an
obvious cause/fix.
This reverts commit r254577.
llvm-svn: 254586
|
| |
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 254585
|
| |
|
|
|
|
|
| |
Thanks Sean Silva for catching this.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 254584
|
| |
|
|
|
|
|
|
|
| |
the Worklist (NFC)
This precludes some more functional changes to perform bulk imports.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 254583
|
| |
|
|
|
|
|
|
|
| |
accurately the actual use.
Thanks Sean Silva for the suggestion.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 254582
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is no real reason the index has to have the concept of an
exporting Module. We should be able to have one single unique
instance of the Index, and it should be read-only after creation
for the whole ThinLTO processing.
The linker plugin should be able to process multiple modules (in
parallel or in sequence) with the same index.
The only reason the ExportingModule was present seems to be to
implement hasExportedFunctions() that is used by the Module linker
to decide what to do with the current Module.
For now I replaced it with a query to the map of Modules path to
see if this module was declared in the Index and consider that if
it is the case then it is probably exporting function.
On the long term the Linker interface needs to evolve and this
call should not be needed anymore.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 254581
|
| |
|
|
|
|
| |
not enough for SPARCv7.
llvm-svn: 254580
|