summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove an unused function, suppress -Wunused-function warning.Haojian Wu2019-08-221-6/+0
| | | | llvm-svn: 369629
* [X86] Lower the cost of v2i32->v2f64 sint_to_fp under vector widening ↵Craig Topper2019-08-223-8/+26
| | | | | | | | | | | | | | legalization. I don't really understand the costs we're using for fp_to_sint, but prior to widening legalization we used 20 as the cost for this via the v2i64->v2f64 entry. That number seems better than the 40 we got with widening legalization. So now we need either a v2i32->v2f64 entry or a v4i32->v2f64 entry depending on whether AVX is enabled or not since we skip the first SSE2 table look up under AVX. llvm-svn: 369628
* [Support] Improve readNativeFile(Slice) interfacePavel Labath2019-08-226-121/+154
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There was a subtle, but pretty important difference between the Slice and regular versions of this function. The Slice function was zero-initializing the rest of the buffer when the read syscall returned less bytes than expected, while the regular function did not. This patch removes the inconsistency by making both functions *not* zero-initialize the buffer. The zeroing code is moved to the MemoryBuffer class, which is currently the only user of this code. This makes the API more consistent, and the code shorter. While in there, I also refactor the functions to return the number of bytes through the regular return value (via Expected<size_t>) instead of a separate by-ref argument. Reviewers: aganea, rnk Subscribers: kristina, Bigcheese, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66471 llvm-svn: 369627
* [ARM] Fix lsrl with a 128/256 bit shift amount or a shift of 32Sam Tebbs2019-08-225-55/+105
| | | | | | | | | | | | | This patch fixes shifts by a 128/256 bit shift amount. It also fixes codegen for shifts of 32 by delegating to LLVM's default optimisation instead of emitting a long shift. Tests that used to generate long shifts of 32 are updated to check for the more optimised codegen. Differential revision: https://reviews.llvm.org/D66519 llvm-svn: 369626
* [lldb][NFC] Remove dead code that is supposed to handle invalid command optionsRaphael Isemann2019-08-2227-217/+82
| | | | | | | | | | | | | | | | | | | | | | | | Summary: We currently have a bunch of code that is supposed to handle invalid command options, but all this code is unreachable because invalid options are already handled in `Options::Parse`. The only way we can reach this code is when we declare but then not implement an option (which will be made impossible with D65386, which is also when we can completely remove the `default` cases). This patch replaces all this code with `llvm_unreachable` to make clear this is dead code that can't be reached. Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66522 llvm-svn: 369625
* [lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and ↵Raphael Isemann2019-08-2257-637/+480
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | remove any undocumented/redundant return values Summary: We still have some leftovers of the old completion API in the internals of LLDB that haven't been replaced by the new CompletionRequest. These leftovers are: * The return values (int/size_t) in all completion functions. * Our result array that starts indexing at 1. * `WordComplete` mode. I didn't replace them back then because it's tricky to figure out what exactly they are used for and the completion code is relatively untested. I finally got around to writing more tests for the API and understanding the semantics, so I think it's a good time to get rid of them. A few words why those things should be removed/replaced: * The return values are really cryptic, partly redundant and rarely documented. They are also completely ignored by Xcode, so whatever information they contain will end up breaking Xcode's completion mechanism. They are also partly impossible to even implement as we assign negative values special meaning and our completion API sometimes returns size_t. Completion functions are supposed to return -2 to rewrite the current line. We seem to use this in some untested code path to expand the history repeat character to the full command, but I haven't figured out why that doesn't work at the moment. Completion functions return -1 to 'insert the completion character', but that isn't implemented (even though we seem to activate this feature in LLDB sometimes). All positive values have to match the number of results. This is obviously just redundant information as the user can just look at the result list to get that information (which is what Xcode does). * The result array that starts indexing at 1 is obviously unexpected. The first element of the array is reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is that we calculate this to make the life of the API caller easier, but obviously forcing people to have 1-based indices is not helpful (or even worse, forces them to manually copy the results to make it 0-based like Xcode has to do). * The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The idea is that we let the top-level API know that we just provided a full completion. Interestingly we `WordComplete` is just a single bool that somehow represents all N completions. And we always provide full completions in LLDB, so in theory it should always be true. The only use it currently serves is providing redundant information about whether we have a single definitive completion or not (which we already know from the number of results we get). This patch essentially removes `WordComplete` mode and makes the result array indexed from 0. It also removes all return values from all internal completion functions. The only non-redundant information they contain is about rewriting the current line (which is broken), so that functionality was moved to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)` to do the same. For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we didn't even implement them in the Editline handler (e.g. -1). I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code, but I would prefer doing this in follow-up NFC commits Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: arphaman, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66536 llvm-svn: 369624
* Revert "[GWP-ASan] Remove c++ standard lib dependency."Petr Hosek2019-08-222-17/+17
| | | | | | | This reverts commit r369606: this doesn't addressed the underlying problem and it's not the correct solution. llvm-svn: 369623
* [TargetLowering] Remove optional arguments passing to makeLibCallShiva Chen2019-08-2210-99/+214
| | | | | | | | | | The patch introduces MakeLibCallOptions struct as suggested by @efriedma on D65497. The struct contain argument flags which will pass to makeLibCall function. The patch should not has any functionality changes. Differential Revision: https://reviews.llvm.org/D65795 llvm-svn: 369622
* [debugserver] Switch back to std::once_flagJonas Devlieghere2019-08-221-1/+1
| | | | | | | We cannot use llvm::once_flag in debugserver because doesn't link against llvm. llvm-svn: 369621
* [lit] Diagnose insufficient args to internal envJoel E. Denny2019-08-226-3/+31
| | | | | | | | | | | | | Without this patch, failing to provide a subcommand to lit's internal `env` results in either a python `IndexError` or an attempt to execute the final `env` argument, such as `FOO=1`, as a command. This patch diagnoses those cases with a more helpful message. Reviewed By: stella.stamenova Differential Revision: https://reviews.llvm.org/D66482 llvm-svn: 369620
* [OpenMP] Permit map with DSA on combined directiveJoel E. Denny2019-08-2213-55/+290
| | | | | | | | | | | | | | | | | | | | | | | | | | | For `map`, the following restriction changed in OpenMP 5.0: * OpenMP 4.5 [2.15.5.1, Restrictions]: "A list item cannot appear in both a map clause and a data-sharing attribute clause on the same construct. * OpenMP 5.0 [2.19.7.1, Restrictions]: "A list item cannot appear in both a map clause and a data-sharing attribute clause on the same construct unless the construct is a combined construct." This patch removes this restriction in the case of combined constructs and OpenMP 5.0, and it updates Sema not to capture a scalar by copy in the target region when `firstprivate` and `map` appear for that scalar on a combined target construct. This patch also adds a fixme to a test that now reveals that a diagnostic about loop iteration variables is dropped in the case of OpenMP 5.0. That bug exists regardless of this patch's changes. Reviewed By: ABataev, jdoerfert, hfinkel, kkwli0 Differential Revision: https://reviews.llvm.org/D65835 llvm-svn: 369619
* [lldb] Replace std::once_flag with llvm::once_flag.Davide Italiano2019-08-222-2/+3
| | | | | | | | | | | | | | | | Summary: The former seems like it's not working on some platforms. All the other uses use `llvm::`, so, let's change for consistency. Reviewers: jasonmolenda, friss Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66566 llvm-svn: 369618
* [FormatManage] Fix the format info orderJonas Devlieghere2019-08-221-2/+3
| | | | | | | The format info entries need to match the order of the enum entries. This should fix the two failing data-formatter tests. llvm-svn: 369617
* [analyzer] Enable control dependency condition tracking by defaultKristof Umann2019-08-225-2/+8
| | | | | | | | This patch concludes my GSoC'19 project by enabling track-conditions by default. Differential Revision: https://reviews.llvm.org/D66381 llvm-svn: 369616
* [analyzer] CastValueChecker: Model isa(), isa_and_nonnull()Csaba Dabis2019-08-224-13/+130
| | | | | | | | | | Summary: - Reviewed By: NoQ Differential Revision: https://reviews.llvm.org/D66423 llvm-svn: 369615
* [FormatManager] Add static_assert to keep formats in sync.Jonas Devlieghere2019-08-221-1/+5
| | | | | | | | This adds a static assert that ensures that there's a format info entry for every format enum value. This should prevent others from making the same mistake I made and Jason kindly fixed in r369611. (Thanks!) llvm-svn: 369614
* [analyzer] Don't track the condition of foreach loopsKristof Umann2019-08-222-0/+38
| | | | | | | | | As discussed on the mailing list, notes originating from the tracking of foreach loop conditions are always meaningless. Differential Revision: https://reviews.llvm.org/D66131 llvm-svn: 369613
* [X86] Making X86OptimizeLEAs pass public. NFCPengfei Wang2019-08-223-26/+30
| | | | | | | | | | | | | | | | Reviewers: wxiao3, LuoYuanke, andrew.w.kaylor, craig.topper, annita.zhang, liutianle, pengfei, xiangzhangllvm, RKSimon, spatel, andreadb Reviewed By: RKSimon Subscribers: andreadb, hiraditya, llvm-commits Tags: #llvm Patch by Gen Pei (gpei) Differential Revision: https://reviews.llvm.org/D65933 llvm-svn: 369612
* The g_format_infos table needs to be updated in concert with theJason Molenda2019-08-221-0/+1
| | | | | | | | | enum Format entries; else we can crash in a place like FormatManager::GetFormatAsCString(). We should add bounds checks to prevent this more reliably, but for tonight I'm just adding this entry to keep an address-sanitizer test run working. llvm-svn: 369611
* [COFF] Fix section name for constants larger than 64 bits on WindowsFangrui Song2019-08-222-1/+99
| | | | | | | | | | | | APIntToHexString returns wrong value ("0000000000000000ffffffffffffffff") for integer larger than 64 bits, and thus TargetLoweringObjectFileCOFF::getSectionForConstant returns same section name for all numbers larger than 64 bits. This patch tries to fix it. Differential Revision: https://reviews.llvm.org/D66458 Patch by Senran Zhang llvm-svn: 369610
* [analyzer] CastValueChecker: Try to fix the buildbotsCsaba Dabis2019-08-221-1/+1
| | | | llvm-svn: 369609
* gn build: Merge r369605Nico Weber2019-08-221-1/+1
| | | | llvm-svn: 369608
* [analyzer] CastValueChecker: Rewrite dead header hotfixCsaba Dabis2019-08-226-6/+6
| | | | llvm-svn: 369607
* [GWP-ASan] Remove c++ standard lib dependency.Petr Hosek2019-08-222-17/+17
| | | | | | | | | | | Remove c++ standard library dependency for now for @phosek. They have a complicated build system that breaks with the fuzzer target here. Also added a todo to remedy later. Differential Revision: https://reviews.llvm.org/D66568 llvm-svn: 369606
* [analyzer] CastValueChecker: Store the dynamic types and castsCsaba Dabis2019-08-2219-537/+914
| | | | | | | | | | | | | | Summary: This patch introduces `DynamicCastInfo` similar to `DynamicTypeInfo` which is stored in `CastSets` which are storing the dynamic cast informations of objects based on memory regions. It could be used to store and check the casts and prevent infeasible paths. Reviewed By: NoQ Differential Revision: https://reviews.llvm.org/D66325 llvm-svn: 369605
* [analyzer] TrackConstraintBRVisitor: Do not track unknown valuesCsaba Dabis2019-08-222-11/+8
| | | | | | | | | | | | Summary: - Reviewers: NoQ, Szelethus Reviewed By: NoQ, Szelethus Differential Revision: https://reviews.llvm.org/D66267 llvm-svn: 369604
* gn build: Merge r369600Nico Weber2019-08-221-0/+3
| | | | llvm-svn: 369603
* [Object] FIX: update PlatformKind name in TapiFileCyndy Ishida2019-08-211-2/+2
| | | | | | | Buildbots that use GCC failed to compile because overwritten namespace with variable name llvm-svn: 369602
* [TSan] #include header instead of forward declaring intercepteesJulian Lettner2019-08-211-18/+5
| | | | llvm-svn: 369601
* [Object] Add tapi files to objectCyndy Ishida2019-08-218-8/+343
| | | | | | | | | | | | | | | | | | | | | Summary: The intention for this is to allow reading and printing symbols out from llvm-nm. Tapi file, and Tapi universal follow a similiar format to their respective MachO Object format. The tests are dependent on llvm-nm processing tbd files which is why its in D66160 Reviewers: ributzka, steven_wu, lhames Reviewed By: ributzka, lhames Subscribers: mgorny, hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66159 llvm-svn: 369600
* [X86] Correct the scheduler classes for TAILJMP and TCRETURN CodeGenOnly ↵Craig Topper2019-08-211-24/+25
| | | | | | | | | | | | instructions. We had an odd combination of WriteJump applied to some memory instructions and WriteJumpLd applied to register and immediate instructions. Thsi should hopefully assign them all correctly. llvm-svn: 369599
* [X86] Replace a couple hardcoded '5's with X86::AddrNumOperands for ↵Craig Topper2019-08-211-2/+3
| | | | | | readability. NFC llvm-svn: 369598
* libcxx: Rename last two .hpp files in libcxx to .hNico Weber2019-08-2110-13/+13
| | | | | | Differential Revision: https://reviews.llvm.org/D66544 llvm-svn: 369597
* [analyzer] Mention whether an event is about a condition in a bug report part 2Kristof Umann2019-08-212-6/+144
| | | | | | | | | In D65724, I do a pretty thorough explanation about how I'm solving this problem, I think that summary nails whats happening here ;) Differential Revision: https://reviews.llvm.org/D65725 llvm-svn: 369596
* [test] Update test so it matches the Windows outputJonas Devlieghere2019-08-211-3/+3
| | | | llvm-svn: 369595
* gn build: Merge r369591Nico Weber2019-08-211-0/+1
| | | | llvm-svn: 369594
* gn build: Merge r369587Nico Weber2019-08-211-0/+1
| | | | llvm-svn: 369593
* [Attributor] FIX: Try to make bots happyJohannes Doerfert2019-08-214-4/+4
| | | | | | | Locally the tight iterations bounds work fine but the bots seem unhappy. Try to get green bots and some time to determine the underlying problem. llvm-svn: 369592
* [LifetimeAnalysis] Support more STL idioms (template forward declaration and ↵Matthias Gehre2019-08-218-15/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | DependentNameType) Summary: This fixes inference of gsl::Pointer on std::set::iterator with libstdc++ (the typedef for iterator on the template is a DependentNameType - we can only put the gsl::Pointer attribute on the underlaying record after instantiation) inference of gsl::Pointer on std::vector::iterator with libc++ (the class was forward-declared, we added the gsl::Pointer on the canonical decl (the forward decl), and later when the template was instantiated, there was no attribute on the definition so it was not instantiated). and a duplicate gsl::Pointer on some class with libstdc++ (we first added an attribute to a incomplete instantiation, and then another was copied from the template definition when the instantiation was completed). We now add the attributes to all redeclarations to fix thos issues and make their usage easier. Reviewers: gribozavr Subscribers: Szelethus, xazax.hun, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66179 llvm-svn: 369591
* [RISCV] Remove fix introduced by r369573, superseded by r369580Luis Marques2019-08-211-3/+0
| | | | llvm-svn: 369590
* [analyzer] Don't make ConditionBRVisitor events prunable when the condition ↵Kristof Umann2019-08-213-36/+164
| | | | | | | | | | | is an interesting field Exactly what it says on the tin! Note that we're talking about interestingness in general, hence this isn't a control-dependency-tracking specific patch. Differential Revision: https://reviews.llvm.org/D65724 llvm-svn: 369589
* [Attributor] Fix: Gracefully handle non-instruction usersJohannes Doerfert2019-08-212-1/+28
| | | | | | | Function can have users that are not instructions, e.g., bitcasts. For now, we simply give up when we see them. llvm-svn: 369588
* Add FileWriter to GSYM and encode/decode functions to AddressRange and ↵Greg Clayton2019-08-2111-25/+395
| | | | | | | | | | | | | | | | AddressRanges The full GSYM patch started with: https://reviews.llvm.org/D53379 This patch add the ability to encode data using the new llvm::gsym::FileWriter class. FileWriter is a simplified binary data writer class that doesn't require targets, target definitions, architectures, or require any other optional compile time libraries to be enabled via the build process. This class needs the ability to seek to different spots in the binary data that it produces to fix up offsets and sizes in GSYM data. It currently uses std::ostream over llvm::raw_ostream because llvm::raw_ostream doesn't support seeking which is required when encoding and decoding GSYM data. AddressRange objects are encoded and decoded to be relative to a base address. This will be the FunctionInfo's start address if the AddressRange is directly contained in a FunctionInfo, or a base address of the containing parent AddressRange or AddressRanges. This allows address ranges to be efficiently encoded using ULEB128 encodings as we encode the offset and size of each range instead of full addresses. This also makes encoded addresses easy to relocate as we just need to relocate one base address. Differential Revision: https://reviews.llvm.org/D63828 llvm-svn: 369587
* [Attributor][NFCI] Introduce tight iteration bounds in the testsJohannes Doerfert2019-08-2115-15/+15
| | | | | | | | | | | | | | | | | Summary: To be able to track how many iterations we need to manifest all information we check for we now make the maximum iteration count explicit. The count is set tightly now and should be kept that way. Reviewers: uenoku, sstefan1 Subscribers: bollu, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66554 llvm-svn: 369586
* NFCI: Simplify SourceManager::translateFile by removing code path that ↵Alex Lorenz2019-08-211-107/+21
| | | | | | | | | | | | | | | should never be taken I noticed that SourceManager::translateFile has code that doesn't really make sense. In particular, if it fails to find a FileID by comparing FileEntry * values, it tries to look through files that have the same filename, to see if they have a matching inode to try to find the right FileID. However, the inode comparison seem redundant, as Clang's FileManager already deduplicates FileEntry * values by inode. Thus the comparisons between inodes should never actually succeed, and the comparison between FileEntry * values should be sufficient here. Differential Revision: https://reviews.llvm.org/D65481 llvm-svn: 369585
* When building file without debug info, include the architectureJason Molenda2019-08-211-1/+5
| | | | | | setting in the cflags on Darwin systems. llvm-svn: 369584
* [analyzer][NFC] Add different interestingness kindsKristof Umann2019-08-213-28/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We defined (on the mailing list and here on phabricator) 2 different cases where retrieving information about a control dependency condition is very important: * When the condition's last write happened in a different stack frame * When the collapse point of the condition (when we can constrain it to be true/false) didn't happen in the actual condition. It seems like we solved this problem with the help of expression value tracking, and have started working on better diagnostics notes about this process. Expression value tracking is nothing more than registering a variety of visitors to construct reports about it. Each of the registered visitors (ReturnVisitor, FindLastStoreVisitor, NoStoreFuncVisitor, etc) have something to go by: a MemRegion, an SVal, an ExplodedNode, etc. For this reason, better explaining a last write is super simple, we can always just pass on some more information to the visitor in question (as seen in D65575). ConditionBRVisitor is a different beast, as it was built for a different purpose. It is responsible for constructing events at, well, conditions, and is registered only once, and isn't a part of the "expression value tracking family". Unfortunately, it is also the visitor to tinker with for constructing better diagnostics about the collapse point problem. This creates a need for alternative way to communicate with ConditionBRVisitor that a specific condition is being tracked for for the reason of being a control dependency. Since at almost all PathDiagnosticEventPiece construction the visitor checks interestingness, it makes sense to pair interestingness with a reason as to why we marked an entity as such. Differential Revision: https://reviews.llvm.org/D65723 llvm-svn: 369583
* Add char8_t support (C++20)Jonas Devlieghere2019-08-219-4/+129
| | | | | | | | | | | | This patch adds support for the char8_t type introduced in C++20 char8_t. The original patch was submitted by James Blachly on the LLDB mailing list [1]. I modified the patch a bit and added a test. [1] http://lists.llvm.org/pipermail/lldb-dev/2019-August/015393.html Differential revision: https://reviews.llvm.org/D66447 llvm-svn: 369582
* Use C++14 heteregenous lookup for a couple of std::map<std::string, ...>Benjamin Kramer2019-08-214-5/+6
| | | | | | | These call find with a StringRef, heterogenous lookup saves a temporary std::string there. llvm-svn: 369581
* [RISCV] Fix use of side-effects in asserts in decoder functionsLuis Marques2019-08-211-6/+9
| | | | llvm-svn: 369580
OpenPOWER on IntegriCloud