| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It is possible that the loop condition can be a boolean constant (infinite loop,
for example). So we sould handle constant condition in annotating a loop. This
patch adds this functionality to support annotating constant condition.
Reviewers: tstellarAMD, arsenm
Subscribers: llvm-commits, arsenm
Differential Revision: http://reviews.llvm.org/D15093
llvm-svn: 260692
|
| |
|
|
|
|
| |
This code is dead. The expansion is now done in HexagonFrameLowering.
llvm-svn: 260691
|
| |
|
|
|
|
|
|
|
| |
We can generate the actual instructions from the intrinsics without the
need for pseudo-instructions. Also, since the intrinsics have a side-
effect in a form of a store, attempt to optimize away loads from the
store location.
llvm-svn: 260690
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Before this change, callee-save registers would be rounded up to even
pairs of GPRs and FPRs. This change eliminates these extra padding
load/stores, though it does keep the stack allocation the same size
unless both the GPR and FPR sets have an odd size, in which case one
full pair stack slot (16 bytes) is saved.
This optimization cannot currently be done for MachO targets since they
rely on a fast-path .debug_frame equivalent that can only encode
callee-save registers as pairs.
Reviewers: t.p.northover, rengolin, mcrosier, jmolloy
Subscribers: aemerson, rengolin, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D17000
llvm-svn: 260689
|
| |
|
|
|
|
|
| |
Create a virtual register that will hold the actual address and use it
with the offset of 0 in the place of the original FI.
llvm-svn: 260688
|
| |
|
|
|
|
| |
Machine model description by Dave Estes <cestes@codeaurora.org>.
llvm-svn: 260686
|
| |
|
|
| |
llvm-svn: 260683
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change merges adjacent 32 bit zero stores into a 64 bit zero store.
e.g.,
str wzr, [x0]
str wzr, [x0, #4]
becomes
str xzr, [x0]
Therefore, four adjacent 32 bit zero stores will be a single stp.
e.g.,
str wzr, [x0]
str wzr, [x0, #4]
str wzr, [x0, #8]
str wzr, [x0, #12]
becomes
stp xzr, xzr, [x0]
Reviewers: mcrosier, jmolloy, gberry, t.p.northover
Subscribers: aemerson, rengolin, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D16933
llvm-svn: 260682
|
| |
|
|
|
|
|
|
|
|
|
| |
The DataLayout can calculate alignment of vectors based on the alignment
of the element type and the number of elements. In fact, it is the product
of these two values. The problem is that for vectors of N x i1, this will
return the alignment of N bytes, since the alignment of i1 is 8 bits. The
vector types of vNi1 should be aligned to N bits instead. Provide explicit
alignment for HVX vectors to avoid such complications.
llvm-svn: 260678
|
| |
|
|
|
|
| |
Found by msan.
llvm-svn: 260676
|
| |
|
|
|
|
|
|
| |
FLOOR.L.D instructions
Differential Revision: http://reviews.llvm.org/D17192
llvm-svn: 260673
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
LLVMGetTargetMachineData has been removed, and LLVMGetDataLayout is
suggested to use. The LLVMGetDataLayout is exposed in go bindings.
So it's safe to remove the function.
Reviewers: bkramer
Subscribers: llvm-commits, axw
Differential Revision: http://reviews.llvm.org/D17193
llvm-svn: 260670
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
node set rather than walking the SCC directly.
This directly exposes the functions and has already had null entries
filtered out. We also don't need need to handle optnone as it has
already been handled in the caller -- we never try to remove convergent
when there are optnone functions in the SCC.
With this change, the code for removing convergent should work with the
new pass manager and a different SCC analysis.
llvm-svn: 260668
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with the test for a non-convergent intrinsic call.
While it is possible to use the call records to search for function
calls, we're going to do an instruction scan anyways to find the
intrinsics, we can handle both cases while scanning instructions. This
will also make the logic more amenable to the new pass manager which
doesn't use the same call graph structure.
My next patch will remove use of CallGraphNode entirely and allow this
code to work with both the old and new pass manager. Fortunately, it
should also get strictly simpler without changing functionality.
llvm-svn: 260666
|
| |
|
|
|
|
| |
on MSVC.
llvm-svn: 260663
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was hardcoded to the static private size, but this
would be missing the offset and additional size for someday
when we have dynamic sizing.
Also stops always initializing flat_scratch even when unused.
In the future we should stop emitting this unless flat instructions
are used to access private memory. For example this will initialize
it almost always on VI because flat is used for global access.
llvm-svn: 260658
|
| |
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 260657
|
| |
|
|
|
|
| |
Replace 'third' with 'fourth' in the description of the fourth argument.
llvm-svn: 260656
|
| |
|
|
| |
llvm-svn: 260655
|
| |
|
|
| |
llvm-svn: 260654
|
| |
|
|
|
|
| |
before I update it to be friendly with the new pass manager.
llvm-svn: 260653
|
| |
|
|
|
|
| |
class that makes it convenient to work with enumerators representing bit options.
llvm-svn: 260652
|
| |
|
|
|
|
|
|
|
| |
Introduce a subtarget feature for this, and leave the default with
the current behavior which assumes up to 16-byte loads/stores can
be used. The field also seems to have the ability to be set to 2 bytes,
but I'm not sure what that would be used for.
llvm-svn: 260651
|
| |
|
|
|
|
| |
every input N times)
llvm-svn: 260649
|
| |
|
|
|
|
|
| |
I don't think this was causing any real problems, so I'm not sure
how to test for this.
llvm-svn: 260646
|
| |
|
|
| |
llvm-svn: 260645
|
| |
|
|
| |
llvm-svn: 260644
|
| |
|
|
|
|
|
|
|
|
|
| |
Patch by Jack Howarth.
When linking to libLLVM, don't also link to the component
libraries that constitute libLLVM.
Differential Revision: http://reviews.llvm.org/D16945
llvm-svn: 260641
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
MSan adds a constructor to each translation unit that calls
__msan_init, and does nothing else. The idea is to run __msan_init
before any instrumented code. This results in multiple constructors
and multiple .init_array entries in the final binary, one per
translation unit. This is absolutely unnecessary; one would be
enough.
This change moves the constructors to a comdat group in order to drop
the extra ones.
llvm-svn: 260632
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Multi-dso programs result in multiple coverage files dumped of the form
'<module_name>.<pid>.sancov'. When analyzing these coverage files it is
important to use correct corresponding object file.
This change removes the "-obj" sancov flag and lets user specify object
file names alongside coverage files. Sancov tool would match them using
<module_name> part of coverage file and short file name of the object
file.
Corresponding changes:
- compiler-rt: http://reviews.llvm.org/D17171
- docs: http://reviews.llvm.org/D17175
Differential Revision: http://reviews.llvm.org/D17169
llvm-svn: 260628
|
| |
|
|
|
|
|
|
|
|
| |
This patches teaches LVI to recognize clamp idioms (e.g. select(a > 5, a, 5) will always produce something greater than 5.
The tests end up being somewhat simplistic because trying to exercise the case I actually care about (a loop with a range check on a clamped secondary induction variable) ends up tripping across a couple of other imprecisions in the analysis. Ah, the joys of LVI...
Differential Revision: http://reviews.llvm.org/D16827
llvm-svn: 260627
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Also, some cosmetic fixes.
Reviewers: arsenm, tstellarAMD
Subscribers: qcolombet, llvm-commits
Differential Revision: http://reviews.llvm.org/D17161
llvm-svn: 260625
|
| |
|
|
| |
llvm-svn: 260623
|
| |
|
|
|
|
| |
Also actually test the default CPU from those triples.
llvm-svn: 260621
|
| |
|
|
|
|
|
| |
It makes it easier to correlate with assembly dumps, which are typically
given with hex offsets.
llvm-svn: 260619
|
| |
|
|
| |
llvm-svn: 260614
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original commit message:
[InstCombine] Fold IntToPtr and PtrToInt into preceding loads.
Currently we only fold a BitCast into a Load when the BitCast is its
only user.
Do the same for any no-op cast.
Patch by Philip Pfaffe!
Differential Revision: http://reviews.llvm.org/D9152
llvm-svn: 260612
|
| |
|
|
|
|
|
|
|
|
|
| |
Summary:
Reasons to remove are twofold:
- we don't really need coverage=1 for libfuzzer operation
- makes controlling coverage for fuzzer processes non-trivial.
Differential Revision: http://reviews.llvm.org/D17168
llvm-svn: 260611
|
| |
|
|
|
|
|
|
|
|
|
| |
Let DAG.getConstant() handle the splatting; there's no need
to repeat that logic here.
See also:
http://reviews.llvm.org/rL258833
http://reviews.llvm.org/rL260582
llvm-svn: 260609
|
| |
|
|
|
|
|
|
|
|
| |
"addFunctionSimplificationPasses()""
This reverts commit r260603.
I didn't intend to push it :(
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 260607
|
| |
|
|
|
|
|
|
| |
This reverts commit r260604.
I didn't intend to push this now.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 260606
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ConstantUniqueMap"
This reverts commit r260458.
It was backported on an internal branch and broke stage2 build. Since
this can lead to weird random crash I'm reverting upstream as well
while investigating.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 260605
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
On the contrary to Full LTO, ThinLTO can afford to shift compile time
from the frontend to the linker: both phases are parallel.
This pipeline is based on the proposal in D13443 for full LTO. We ]
didn't move forward on this proposal because the link was far too long
after that.
This patch refactor the "function simplification" passes that are part
of the inliner loop in a helper function (this part is NFC and can be
commited separately to simplify the diff). The ThinLTO pipeline
integrates in the regular O2/O3 flow:
- The compile phase perform the inliner with a somehow lighter
function simplification. (TODO: tune the inliner thresholds here)
This is intendend to simplify the IR and get rid of obvious things
like linkonce_odr that will be inlined.
- The link phase will run the pipeline from the start, extended with
some specific passes that leverage the augmented knowledge we have
during LTO. Especially after the inliner is done, a sequence of
globalDCE/globalOpt is performed, followed by another run of the
"function simplification" passes.
The measurements on the public test suite as well as on our internal
suite show an overall net improvement. The binary size for the clang
executable is reduced by 5%. We're still tuning it with the bringup
of ThinLTO but this should provide a good starting point.
Reviewers: tejohnson
Subscribers: joker.eph, llvm-commits, dexonsmith
Differential Revision: http://reviews.llvm.org/D17115
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 260604
|
| |
|
|
|
|
|
|
| |
It is intended to contains the passes run over a function after the
inliner is done with a function and before it moves to its callers.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 260603
|
| |
|
|
|
|
| |
PR26161.
llvm-svn: 260602
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is just a trivial implementation:
- Support only arguments passed in registers.
- Support only "plain" arguments, i.e., no sext/zext attribute.
At this point, it is possible to play with the IRTranslator on AArch64:
llc -mtriple arm64-<vendor>-<os> -print-machineinstrs <input.ll> -o - -global-isel
For now, we only support the translation of program with adds and returns.
Follow-up patches are on their way to add a test case (the MIRParser is
not ready as it is).
llvm-svn: 260600
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It's possible to have resource descriptors and samplers stored in
VGPRs, either by a VMEM instruction or in the case of samplers,
floating-point calculations. When this happens, we need to use
v_readfirstlane to copy these values back to sgprs.
Reviewers: mareko, arsenm
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D17102
llvm-svn: 260599
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This required to add binding to Instruction::removeFromParent so that instruction can be forward declared and then moved at the right place.
Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17057
llvm-svn: 260597
|
| |
|
|
| |
llvm-svn: 260594
|
| |
|
|
| |
llvm-svn: 260593
|