| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 294761
|
|
|
|
|
|
| |
Thanks Davide to catch it in my previous patch.
llvm-svn: 294759
|
|
|
|
|
|
|
| |
lib/Target/X86/X86TargetMachine.cpp has a code that deletes an instance of a
LegalizerInfo descendant via a pointer to base.
llvm-svn: 294757
|
|
|
|
| |
llvm-svn: 294756
|
|
|
|
|
|
|
|
|
| |
We previously only created a vector phi node for an induction variable if its
type matched the type of the canonical induction variable.
Differential Revision: https://reviews.llvm.org/D29776
llvm-svn: 294755
|
|
|
|
| |
llvm-svn: 294753
|
|
|
|
|
|
|
|
|
| |
This makes sure we get the same redefinition rules regardless of who
is printing (asm parser, codegen) and to what (asm, obj).
This fixes an unintentional regression in r293936.
llvm-svn: 294752
|
|
|
|
|
|
| |
Tests to demonstrate throughput-latency decision between div and rcp on faster hardware such as Haswell
llvm-svn: 294750
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
legalization
The patch comes in 2 parts:
1 - it makes use of the SelectionDAG::NewNodesMustHaveLegalTypes flag to tell when it can safely constant fold illegal types.
2 - it correctly resets SelectionDAG::NewNodesMustHaveLegalTypes at the start of each call to SelectionDAGISel::CodeGenAndEmitDAG so all the pre-legalization stages can make use of it - not just the first basic block that gets handled.
Fix for PR30760
Differential Revision: https://reviews.llvm.org/D29568
llvm-svn: 294749
|
|
|
|
|
|
| |
Also reordered an if statement to test low cost comparisons first
llvm-svn: 294748
|
|
|
|
|
|
|
| |
In some cases we call getTargetConstantBitsFromNode for nodes that haven't been lowered from BUILD_VECTOR yet
Note: We're getting very close to being able to move most of the constant extraction code from getTargetShuffleMaskIndices into getTargetConstantBitsFromNode
llvm-svn: 294746
|
|
|
|
| |
llvm-svn: 294745
|
|
|
|
|
|
| |
compilers don't print the typedef name.
llvm-svn: 294729
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without any loops, we don't even bother to build the standard analyses
used by loop passes. Without these, we can't run loop analyses or
invalidate them properly. Unfortunately, we did these things in the
wrong order which would allow a loop analysis manager's proxy to be
built but then not have the standard analyses built. When we went to do
the invalidation in the proxy thing would fall apart. In the test case
provided, it would actually crash.
The fix is to carefully check for loops first, and to in fact build the
standard analyses before building the proxy. This allows it to
correctly trigger invalidation for those standard analyses.
An alternative might seem to be to look at whether there are any loops
when doing invalidation, but this doesn't work when during the loop
pipeline run we delete the last loop. I've even included that as a test
case. It is both simpler and more robust to defer building the proxy
until there are definitely the standard set of analyses and indeed
loops.
This bug was uncovered by enabling GlobalsAA in the pipeline.
llvm-svn: 294728
|
|
|
|
| |
llvm-svn: 294726
|
|
|
|
| |
llvm-svn: 294725
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
[X86][GlobalISel] Add general-purpose Register Bank.
Add trivial handling of G_ADD legalization .
Add Regestry Bank selection for COPY and G_ADD instructions
Reviewers: rovka, zvi, ab, t.p.northover, qcolombet
Reviewed By: qcolombet
Subscribers: qcolombet, mgorny, dberris, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D29771
llvm-svn: 294723
|
|
|
|
|
|
|
|
| |
Follow-up to D29005.
Differential Revision: https://reviews.llvm.org/D29005
llvm-svn: 294722
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In preparation for graph comparison and filtering, this is a library for
representing graphs in LLVM. This will enable easier encapsulation and reuse
of graphs in llvm-xray.
Depends on D28999, D28225
Reviewers: dblaikie, dberris
Reviewed By: dberris
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29005
llvm-svn: 294717
|
|
|
|
|
|
|
|
| |
Chandler mentioned at the last social that the need for BFI in the new pass manager was causing a slight hiccup for this pass. Given this code has been checked in, but off for over a year, it makes sense to just remove it for now.
Note that there's nothing wrong with the general idea - it's actually a quite good one - and once we have the infrastructure in place to implement this without the full recompuation on every loop, we absolutely should.
llvm-svn: 294715
|
|
|
|
|
|
| |
Broke tests, reverting.
llvm-svn: 294714
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In preparation for graph comparison and filtering, this is a library for
representing graphs in LLVM. This will enable easier encapsulation and reuse
of graphs in llvm-xray.
Depends on D28999, D28225
Reviewers: dblaikie, dberris
Reviewed By: dberris
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29005
llvm-svn: 294713
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
type legalization
Summary:
With -debug, we aren't dumping the DAG after legalizing vector ops. In particular, on X86 with AVX1 only, we don't dump the DAG after we split 256-bit integer ops into pairs of 128-bit ADDs since this occurs during vector legalization.
I'm only dumping if the legalize vector ops changes something since we don't print anything during legalize vector ops. So this dump shows up right after the first type-legalization dump happens. So if nothing changed this second dump is unnecessary.
Having said that though, I think we should probably fix legalize vector ops to log what its doing.
Reviewers: RKSimon, eli.friedman, spatel, arsenm, chandlerc
Reviewed By: RKSimon
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D29554
llvm-svn: 294711
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Small fix to HtmlFormatter, defaults to ascii encoding, so utf-8 output may get `UnicodeEncodeError: 'ascii' codec can't encode character ... ordinal not in range(128)` during write.
Patch by Brian Cain!
Reviewers: anemet, fhahn
Reviewed By: anemet
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29802
llvm-svn: 294710
|
|
|
|
|
|
|
|
|
| |
until we can get better TargetMachine::isCompatibleDataLayout to compare - otherwise
we can't code generate existing bitcode without a string equality data layout.
This reverts commit r294702.
llvm-svn: 294709
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of emitting the matcher code directly, return the rule matcher
and the skip reason as an Expected<RuleMatcher>.
This will let us record all matchers and process them before emission.
It's a somewhat unconventional use of Error, but it's nicer than, say,
std::pair, because of the bool conversions.
Differential Revision: https://reviews.llvm.org/D29743
llvm-svn: 294706
|
|
|
|
|
|
|
|
|
|
| |
The ARM target is getting really close to the current limit of 128
subtarget features already breaking out of tree enhancements. Increase
the size once more to 196.
I filed http://llvm.org/PR31926 to request a proper solution.
llvm-svn: 294704
|
|
|
|
|
|
|
|
|
|
|
|
| |
For other platforms we should find out what they need and likely
make the same change, however, a smaller additional change is easier
for platforms we know have it specified in the ABI. As part of this
rewrite some of the handling in the backends for data layout and update
a bunch of testcases.
Based on a patch by Simonas Kazlauskas!
llvm-svn: 294702
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Inside an alias group, when ordering instruction aliases, we rely
on the priority field to sort them.
When the priority is not set or more generally when there is a tie between
two aliases, we used to rely on the lexicographic order. However, this
order can change for the anonymous records when more instruction, intrinsic,
etc. are inserted.
For instance, given two anonymous records r1 and r2 with respective name
A_999 and A_1000, their lexicography order will be r2 then r1. Now, if
an instruction is added before them, their name will become respectively
A_1000 and A_1001, thus the lexicography order will be r1 then r2, i.e.,
it changed.
If that happens in an alias group, the assembly output would prefer a
different alias for no apparent good reasons.
A way to fix that is to use proper priority for all aliases, but we
can also make the tie breaker comparison smarter and use a deterministic
ordering. This is what this patch does.
llvm-svn: 294695
|
|
|
|
| |
llvm-svn: 294694
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D26010
llvm-svn: 294692
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change returns empty PSet list for M0 register. Otherwise its
PSet as defined by tablegen is SReg_32. This results in incorrect
register pressure calculation every time an instruction uses M0.
Such uses count as SReg_32 PSet and inadequately increase pressure
on SGPRs.
Differential Revision: https://reviews.llvm.org/D29798
llvm-svn: 294691
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM defines `PTHREAD_LIB` which is used by AddLLVM.cmake and various projects
to correctly link the threading library when needed. Unfortunately
`PTHREAD_LIB` is defined by LLVM's `config-ix.cmake` file which isn't installed
and therefore can't be used when configuring out-of-tree builds. This causes
such builds to fail since `pthread` isn't being correctly linked.
This patch attempts to fix that problem by renaming and exporting
`LLVM_PTHREAD_LIB` as part of`LLVMConfig.cmake`. I renamed `PTHREAD_LIB`
because It seemed likely to cause collisions with downstream users of
`LLVMConfig.cmake`.
llvm-svn: 294690
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to export external functions so they are found when calling
GetProcAddress() on Windows. But we can't use `__declspec(dllexport)` because
we want the targets to be completely independent from the fuzz engines and don't
depend on other header files. Also, we don't want to include platform specific
code managed with conditional macros.
So, the solution is to add the exported symbols with linker flags in cmake.
Differential revision: https://reviews.llvm.org/D29752
llvm-svn: 294688
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace weak aliases with dynamic loading.
Weak aliases were generating some problems when linking for MT on Windows. For
MT, compiler-rt's libraries are statically linked to the main executable the
same than libFuzzer, so if we use weak aliases, we are providing two different
default implementations for the same weak function and the linker fails.
In this diff I re implement ExternalFunctions() using dynamic loading, so it
works in both cases (MD and MT). Also, dynamic loading is simpler, since we are
not defining any auxiliary external function, and we don't need to deal with
weak aliases.
This is equivalent to the implementation using dlsym(RTLD_DEFAULT, FnName) for
Posix.
Differential revision: https://reviews.llvm.org/D29751
llvm-svn: 294687
|
|
|
|
|
|
|
|
| |
Patch by Jorge Gorbe (lethalantidote).
Differential Revision: https://reviews.llvm.org/D29797
llvm-svn: 294686
|
|
|
|
|
|
| |
minor fixes (NFC).
llvm-svn: 294685
|
|
|
|
| |
llvm-svn: 294682
|
|
|
|
| |
llvm-svn: 294679
|
|
|
|
| |
llvm-svn: 294678
|
|
|
|
|
|
|
| |
Change syntax to have enum elements sorted alphabetically and one per
line as that is more merge/cherry pick friendly.
llvm-svn: 294677
|
|
|
|
|
|
|
|
| |
Add support for padded SLEB128 values, and support for writing SLEB128
values to buffers rather than to ostreams, similar to the existing
ULEB128 support.
llvm-svn: 294675
|
|
|
|
| |
llvm-svn: 294674
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pygments syntax highlighting package used by sphinx fails to parse
newer LLVM constructs or valid (at least to me) gas constructs like
`.secrel32 _function_name + 0`.
Disable this particular warning so the build doesn't abort as fixing
pygments doesn't seem a workable option here.
Differential Revision: https://reviews.llvm.org/D29794
llvm-svn: 294672
|
|
|
|
|
|
|
|
|
|
|
| |
This needs explicit requires of the optimization remark emission before
loop pass pipelines containing LICM as we no longer get it from the
inliner -- Argument Promotion may invalidate it. Technically the inliner
could also have broken this, but it never came up in testing.
Differential Revision: https://reviews.llvm.org/D29595
llvm-svn: 294670
|
|
|
|
| |
llvm-svn: 294668
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that the call graph supports efficient replacement of a function and
spurious reference edges, we can port ArgumentPromotion to the new pass
manager very easily.
The old PM-specific bits are sunk into callbacks that the new PM simply
doesn't use. Unlike the old PM, the new PM simply does argument
promotion and afterward does the update to LCG reflecting the promoted
function.
Differential Revision: https://reviews.llvm.org/D29580
llvm-svn: 294667
|
|
|
|
|
|
|
|
| |
evaluating them.
This was crashing before.
llvm-svn: 294666
|
|
|
|
|
|
| |
I hope this fixes the clang-stage2-cmake-modules jenkins build.
llvm-svn: 294665
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Somewhat amazingly, this only requires teaching it to clean them up when
deleting a dead function from the graph. And we already have exactly the
necessary data structures to do that in the parent RefSCCs.
This allows ArgPromote to work in a much simpler way be merely letting
reference edges linger in the graph after the causing IR is deleted. We
will clean up these edges when we run any function pass over the IR, but
don't remove them eagerly.
This avoids all of the quadratic update issues both in the current pass
manager and in my previous attempt with the new pass manager.
Differential Revision: https://reviews.llvm.org/D29579
llvm-svn: 294663
|