| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Lets us get rid of one member variable too.
Reviewers: arsenm
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D26992
llvm-svn: 287716
|
| |
|
|
|
|
| |
-lcudart_static doesn't work. We don't know why.
llvm-svn: 287715
|
| |
|
|
| |
llvm-svn: 287714
|
| |
|
|
|
|
|
| |
complete a little more general; it is produced in other cases than the one that
it previously talked about.
llvm-svn: 287713
|
| |
|
|
| |
llvm-svn: 287712
|
| |
|
|
|
|
| |
Fixes PR31126.
llvm-svn: 287711
|
| |
|
|
|
|
|
|
| |
info. (NFC)
If there is no debug info in the callee, inlining it will not help annotator. This avoids infinite loop as reported in PR/31119.
llvm-svn: 287710
|
| |
|
|
|
|
|
|
|
|
| |
We visit and/or, we try to derive a lattice value for the
instruction even if one of the operands is overdefined.
If the non-overdefined value is still 'unknown' just return and wait
for ResolvedUndefsIn to "plug in" the correct value. This simplifies
the logic a bit. While I'm here add tests for missing cases.
llvm-svn: 287709
|
| |
|
|
|
|
|
|
|
|
|
|
| |
TargetSubtargetInfo is filled with CodeGen specific interfaces nowadays
(getInstrInfo(), getFrameLowering(), getSelectionDAGInfo()) most of the
tuning flags like enablePostRAScheduler(), getAntiDepBreakMode(),
enableRALocalReassignment(), ... also do not seem to be universal enough
to make sense outside of CodeGen.
Differential Revision: https://reviews.llvm.org/D26948
llvm-svn: 287708
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In PR27925:
https://llvm.org/bugs/show_bug.cgi?id=27925
...we proposed adding this fold to eliminate a bitcast. In D20774, there was
some concern about changing the type of a bitwise op as well as creating
bitcasts that might not be free for a target. However, if we're strictly
eliminating an instruction (by limiting this to one-use ops), then we should
be able to do this in InstCombine.
But we're cautiously restricting the transform for now to vector types to
avoid possible backend problems. A transform to make sure the logic op is
legal for the target should be added to reverse this transform and improve
codegen.
Differential Revision: https://reviews.llvm.org/D26641
llvm-svn: 287707
|
| |
|
|
| |
llvm-svn: 287706
|
| |
|
|
|
|
| |
No intended change, everything seems to be in working order already.
llvm-svn: 287705
|
| |
|
|
| |
llvm-svn: 287704
|
| |
|
|
|
|
| |
Regular maintenance update with only minor changes.
llvm-svn: 287703
|
| |
|
|
| |
llvm-svn: 287702
|
| |
|
|
| |
llvm-svn: 287701
|
| |
|
|
|
|
|
| |
Reviewer: Hal Finkel.
Differential Revision: https://reviews.llvm.org/D26952
llvm-svn: 287700
|
| |
|
|
|
|
|
|
| |
Now that lld switched to lib/LTO, which always calls setDataLayout(),
we don't need this check anymore.
Thanks to Peter for pointing out!
llvm-svn: 287699
|
| |
|
|
|
|
|
|
| |
This mostly gives us nice unittesting of the predicates themselves. I'll
start using them further in subsequent commits to help test the actual
operations performed on the graph.
llvm-svn: 287698
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PDBFileBuilder supports two different ways to create files.
One is PDBFileBuilder::commit. That function takes a filename
and write a result to the file. The other is PDBFileBuilder::build.
That returns a new PDBFile object.
This patch removes the latter because no one is using it and
in a real life situation we are very unlikely to need it.
Even if you need it, it'd be easy to write a new PDB to a memory
buffer and read it back.
Removing PDBFileBuilder::build enables us to remove other classes
build transitively.
Differential Revision: https://reviews.llvm.org/D26987
llvm-svn: 287697
|
| |
|
|
|
|
|
|
| |
user's home directory contains "bar"
Differential Revision: https://reviews.llvm.org/D24605
llvm-svn: 287696
|
| |
|
|
|
|
|
| |
Reviewer: Hal Finkel.
Differential Revision: https://reviews.llvm.org/D26957
llvm-svn: 287695
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce the new flag -polly-codegen-generate-expressions which forces Polly
to code generate AST expressions instead of using our SCEV based access
expression generation even for cases where the original memory access relation
was not changed and the SCEV based access expression could be code generated
without any issue.
This is an experimental option for better testing the isl ast expression
generation. The default behavior of Polly remains unchanged. We also exclude
a couple of cases for which the AST expression is not yet working.
llvm-svn: 287694
|
| |
|
|
|
|
|
|
|
| |
Libc++ internal uses <atomic> in C++03 code but the module map forbids its use.
This causes the libc++ 'std' module to fail to build in C++03.
This patch removes the requirement to fix this issue.
llvm-svn: 287693
|
| |
|
|
| |
llvm-svn: 287692
|
| |
|
|
| |
llvm-svn: 287691
|
| |
|
|
| |
llvm-svn: 287690
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21741
llvm-svn: 287689
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently, TargetLibraryInfoWrapperPass is inserted by PMBuilder.
However, some passes are inserted manually before the PMBuilder
ones - if any of them happens to use TargetLibraryInfoWrapperPass,
it'll get a default-constructed one, with an unknown target triple.
This happens to InstrProfiling in D21736, breaking it.
Differential Revision: http://reviews.llvm.org/D21737
llvm-svn: 287688
|
| |
|
|
| |
llvm-svn: 287687
|
| |
|
|
|
|
|
|
| |
Will help a pending patch.
Differential Revision: http://reviews.llvm.org/D26982
llvm-svn: 287686
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://reviews.llvm.org/D25932 made it so that clang always checks if
libLTO.dylib is present on disk, even if -flto is not being used. The
motivation for that change was that if a dependency happens to contain bitcode,
ld64 will try to load libLTO without -flto explicitly being enabled. However,
the change had the undesirable side effect of warning if libLTO.dylib doesn't
exist even if it isn't needed.
Change things so that -lto_library is always passes, independent of if it
exists or not. ld64 only looks at this flag if it uses LTO. If the dylib
exists, all is well. If it doesn't, and LTO is not being used, all is well too.
If ld64 does end up using LTO and the dylib does not exist, ld64 will print
something like
ld: could not process llvm bitcode object file, because foo/libLTO.dylib could not be loaded file 'test.o' for architecture x86_64
https://reviews.llvm.org/D26984
llvm-svn: 287685
|
| |
|
|
|
|
|
|
|
| |
Add a compiler vendor for Facebook, to enable future vendor-specific
behavior.
Differential Revision: https://reviews.llvm.org/D25136
llvm-svn: 287684
|
| |
|
|
|
|
|
| |
We cannot have MipsRldMap class and In<ELFT>::MipsRldMap.
Renamed the class.
llvm-svn: 287683
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SCCs.
These will be fairly expensive routines to call and might be abused in
real code, but are quite useful when debugging or in asserts and are
reasonable and well formed properties to query.
I've used one of them in an assert that was requested in a code review
here. In subsequent commits I'll start using these routines more
heavily, for example in unittests etc. But this at least gets the
groundwork in place.
Differential Revision: https://reviews.llvm.org/D25506
llvm-svn: 287682
|
| |
|
|
|
|
|
|
|
|
| |
Add the single operand form.
Reviewers: vkalintiris
Differential Revision: https://reviews.llvm.org/D26961
llvm-svn: 287681
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26485
llvm-svn: 287680
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch corresponds to review:
https://reviews.llvm.org/D26861
It also fixes PR30730.
Committing on behalf of Lei Huang.
llvm-svn: 287679
|
| |
|
|
|
|
|
|
| |
Better coverage of all legal types + special cases.
Removed old fptoui tests which are all handled in fptoui.ll
llvm-svn: 287678
|
| |
|
|
|
|
|
|
| |
GNU LD allows `ASSERT` commands to be in output section descriptions.
Note that LD also mandates that `ASSERT` commands in this context must
end with a semicolon.
llvm-svn: 287677
|
| |
|
|
|
|
|
|
| |
This occurs during UINT_TO_FP v2f64 lowering.
We can easily generalize this to other horizontal ops (FHSUB, PACKSS, PACKUS) as required - we are doing something similar with PACKUS in lowerV2I64VectorShuffle
llvm-svn: 287676
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D26958
llvm-svn: 287675
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
looking for a point
Due to the way the preprocessor works nodes can be half in a macro or a
different file. This means checking the file name of the start location
of a Decl is not a correct way of checking if the entire Decl is in that
file. Remove that flawed assumption and replace it with a more effective
check: If the point we're looking for is *inside* of the begin and end
location of a Decl, look inside.
This should make clang-rename more reliable (for example macro'd namespaces
threw it off before, as seen in the test case) and maybe a little faster
by pruning off more stuff that the RecursiveASTVisitor doesn't have to
drill into.
llvm-svn: 287649
|
| |
|
|
|
|
| |
This fixes the build breakage due to the use of C++14.
llvm-svn: 287647
|
| |
|
|
|
|
|
|
| |
Add missing unaligned store macros (ush/usw) and fix the exisiting
implementation of the unaligned load macros in order to generate
identical expansions with the GNU assembler.
llvm-svn: 287646
|
| |
|
|
|
|
|
|
|
| |
No-one actually had a mangler handy when calling this function, and
getSymbol itself went most of the way towards getting its own mangler
(with a local TLOF variable) so forcing all callers to supply one was
just extra complication.
llvm-svn: 287645
|
| |
|
|
| |
llvm-svn: 287644
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Splat vectors are canonicalized to BUILD_VECTOR's so the code can be simplified. NFC-ish.
Reviewers: craig.topper, delena, RKSimon, andreadb
Subscribers: RKSimon, llvm-commits
Differential Revision: https://reviews.llvm.org/D26678
llvm-svn: 287643
|
| |
|
|
| |
llvm-svn: 287642
|
| |
|
|
| |
llvm-svn: 287640
|