| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This change adds SMAC (signed multiply-accumulate) and UMAC (unsigned multiply-accumulate) for LEON subtargets of the Sparc processor.
The new files LeonFeatures.td and leon-instructions.ll will both be expanded in future, so I want to leave them separate as small files for this review, to be expanded in future check-ins.
Note: The functions are provided only for inline-assembly provision. No DAG selection is provided.
Differential Revision: http://reviews.llvm.org/D19911
llvm-svn: 268908
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This implements the lowering of the X constraint on
AArch64.
The default behaviour of the X constraint lowering is to
restrict it to "f". This is a problem because the "f"
constraint is not implemented on AArch64 and would be too
restrictive anyway. Therefore, the AArch64 hook will
lower this to "w" (if the operand is a floating point or
vector) or "r" otherwise.
The implementation is similar with the one added for
ARM (r267411).
This is the AArch64 side of the fix for http://llvm.org/PR26493
Reviewers: rengolin
Subscribers: aemerson, rengolin, llvm-commits, t.p.northover
Differential Revision: http://reviews.llvm.org/D19967
llvm-svn: 268907
|
| |
|
|
|
|
|
|
| |
Fixes use after free but breaks tests.
This reverts commit r268901.
llvm-svn: 268902
|
| |
|
|
| |
llvm-svn: 268901
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In theory, care must be taken to ensure that pairs of R_MIPS_(GOT|HI|LO)16
make the same decision on both relocs in the reloc pair but in practice
this isn't as hard as it sounds and only limits the complexity of the
predicate used. We handle all three with the same code to ensure their
decisions always agree with each other.
Reviewers: sdardis
Subscribers: rafael, dsanders, sdardis, llvm-commits
Differential Revision: http://reviews.llvm.org/D19016
llvm-svn: 268900
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D10640
llvm-svn: 268896
|
| |
|
|
| |
llvm-svn: 268892
|
| |
|
|
|
|
| |
and int_x86_avx512_mask_cvtss2sd_round. Only the argument being converted should be a different type. The other 2 argument should have the same type as the result.
llvm-svn: 268891
|
| |
|
|
| |
llvm-svn: 268889
|
| |
|
|
| |
llvm-svn: 268888
|
| |
|
|
|
|
|
|
| |
vXi8/vXi16/vXi32 when VLX is enabled. The equivalent AVX1/2 patterns are disabled by VLX.
This caused regular stores to be emitted instead.
llvm-svn: 268886
|
| |
|
|
|
|
|
|
| |
stay enabled unless VLX and BWI instructions are supported."
Without this we could fail instruction selection if VLX was enabled, but BWI wasn't.
llvm-svn: 268885
|
| |
|
|
|
|
| |
encoded VPXORD so all 32 registers can be used.
llvm-svn: 268884
|
| |
|
|
|
|
| |
always canonicalized to v4i32/v8i32/v16i32 except for in SSE1 only when only v4f32 is supported.
llvm-svn: 268880
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A number of libcalls don't exist in any particular lib but are, instead,
defined in math.h as inline functions (even in C mode!). Don't rely on
their existence when lowering @llvm.{cos,sin,floor,..}.f32, promote them
instead.
N.B. We had logic to handle FREM but were missing out on a number of
others. This change generalizes the FREM handling.
llvm-svn: 268875
|
| |
|
|
|
|
| |
Either way a 256-bit VXORPS will be used.
llvm-svn: 268873
|
| |
|
|
|
|
| |
supported. While there, add a predicate to the SSE2 patterns to avoid an ordering dependency.
llvm-svn: 268872
|
| |
|
|
|
|
| |
only AVX1 is supported. AVX_SET0 just expands to 256-bit VXORPS which is legal in AVX1.
llvm-svn: 268871
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(re-apply r268810 as it exposed an uninitialized variable in ARM MFI.
Patch 268868 should fix that.)
Summary:
Currently, when checking if a stack is "BigStack" or not, it doesn't count into spills and arguments. Therefore, LLVM won't reserve spill slot for this actually "BigStack". This may cause scavenger failure.
Reviewers: rengolin
Subscribers: vitalybuka, aemerson, rengolin, tberghammer, danalbert, srhines, llvm-commits
Differential Revision: http://reviews.llvm.org/D19896
llvm-svn: 268869
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Explicitly initialize ArgumentStackSize to prevent the msan failure.
Reviewers: rengolin
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: http://reviews.llvm.org/D20051
llvm-svn: 268868
|
| |
|
|
| |
llvm-svn: 268867
|
| |
|
|
|
|
| |
Added bitreverse creation testing
llvm-svn: 268865
|
| |
|
|
|
|
| |
in 64-bit mode.
llvm-svn: 268863
|
| |
|
|
| |
llvm-svn: 268861
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the sake of minimalism, this patch is x86 only, but I think that at least
PPC, ARM, AArch64, and Sparc probably want to do this too.
We might want to generalize the hook and pattern recognition for a target like
PPC that has a full assortment of negated logic ops (orc, nand).
Note that http://reviews.llvm.org/D18842 will cause this transform to trigger
more often.
For reference, this relates to:
https://llvm.org/bugs/show_bug.cgi?id=27105
https://llvm.org/bugs/show_bug.cgi?id=27202
https://llvm.org/bugs/show_bug.cgi?id=27203
https://llvm.org/bugs/show_bug.cgi?id=27328
Differential Revision: http://reviews.llvm.org/D19087
llvm-svn: 268858
|
| |
|
|
| |
llvm-svn: 268851
|
| |
|
|
|
|
|
|
|
| |
deleting it.
Fix MSAN build.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 268849
|
| |
|
|
|
|
| |
[-Wunused-function]
llvm-svn: 268848
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves the code that handles stripping debug info intrinsic from
StripDebugInfo(Module) to StripDebugInfo(Function). The latter is
already walking every instructions so it makes sense to do it at the
same time.
This makes also stripDebugInfo(Function) as an API more useful: it
is really dropping every debug info in the Function.
Finally the existing code is trigerring an assertion when the Module
is not fully materialized.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 268847
|
| |
|
|
|
|
|
|
| |
This enables lazy JITing on Windows x86-64.
Patch by David. Thanks David!
llvm-svn: 268845
|
| |
|
|
|
|
| |
It breaks many bots
llvm-svn: 268837
|
| |
|
|
|
|
| |
There is no need to match the comparison instruction repeatedly.
llvm-svn: 268836
|
| |
|
|
| |
llvm-svn: 268835
|
| |
|
|
| |
llvm-svn: 268834
|
| |
|
|
|
|
|
| |
16802==WARNING: MemorySanitizer: use-of-uninitialized-value
lib/Target/ARM/ARMFrameLowering.cpp:1632
llvm-svn: 268833
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves the code that handles stripping debug info intrinsic from
StripDebugInfo(Module) to StripDebugInfo(Function). The latter is
already walking every instructions so it makes sense to do it at the
same time.
This makes also stripDebugInfo(Function) as an API more useful: it
is really dropping every debug info in the Function.
Finally the existing code is trigerring an assertion when the Module
is not fully materialized.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 268832
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This re-applies r268760, reverted in r268794.
Fixes http://llvm.org/PR27670
The original imp-defs assertion was way overzealous: forward all
implicit operands, except imp-defs of the new super-reg def (r268787
for GR64, but also possible for GR16->GR32), or imp-uses of the new
super-reg use.
While there, mark the source use as Undef, and add an imp-use of the
old source reg: that should cover any case of dead super-regs.
At the stage the pass runs, flags are unlikely to matter anyway;
still, let's be as correct as possible.
Also add MIR tests for the various interesting cases.
Original commit message:
Codesize is less (16) or equal (8), and we avoid partial
dependencies.
Differential Revision: http://reviews.llvm.org/D19999
llvm-svn: 268831
|