- Feb 13, 2016
-
-
Chris Bieneman authored
This was originally a hacky if(APPLE) block. Now that we have an option for enabling LTO, it is better to properly gate this. llvm-svn: 260707
-
Chad Rosier authored
In short, before r252926 we were comparing an unsigned (StoreSize) against an a APInt (Stride), which is fine and well. After we were zero extending the Stride and then converting to an unsigned, which is not the same thing. Obviously, Stides can also be negative. This commit just restores the original behavior. AFAICT, it's not possible to write a test case to expose the issue because the code already has checks to make sure the StoreSize can't overflow an unsigned (which prevents the Stride from overflowing an unsigned as well). llvm-svn: 260706
-
Philip Reames authored
As the title says. Modelled after similar code in SCEV. This is useful when analysing induction variables in loops which have been canonicalized by other passes. I wrote the tests as non-loops specifically to avoid the generality introduced in http://reviews.llvm.org/D17174. While that can handle many induction variables without *needing* to exploit nsw, there's no reason not to use it if we've already proven it. Differential Revision: http://reviews.llvm.org/D17177 llvm-svn: 260705
-
Hans Wennborg authored
When cmake is run with -DLLVM_ENABLE_PIC=OFF, build fails while linking shared library libLTO.so, because its dependencies are built with -fno-PIC. More details here: https://llvm.org/bugs/show_bug.cgi?id=26484. This diff reverts r252652 (git 9fd4377ddb83aee3c049dc8757e7771edbb8ee71), which removed check NOT LLVM_ENABLE_PIC before disabling build for libLTO.so. Patch by Igor Sugak! Differential Revision: http://reviews.llvm.org/D17049 llvm-svn: 260703
-
Mehdi Amini authored
Other component could not depends on an optional library in llvm-config From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 260701
-
Mehdi Amini authored
From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 260700
-
Sean Callanan authored
Test cases should not be named after PR or Radar numbers. It's fine to annotate them with these numbers in comments, however. llvm-svn: 260699
-
Krzysztof Parzyszek authored
llvm-svn: 260698
-
Artem Belevich authored
This is an artefact of split-mode CUDA compilation that we need to mimic. HD functions are sometimes allowed to call H or D functions. Due to split compilation mode device-side compilation will not see host-only function and thus they will not be considered at all. For clang both H and D variants will become function overloads visible to compiler. Normally target attribute is considered only if C++ rules can not determine which function is better. However in this case we need to ignore functions that would not be present during current compilation phase before we apply normal overload resolution rules. Changes: * introduced another level of call preference to better describe possible call combinations. * removed WrongSide functions from consideration if the set contains SameSide function. * disabled H->D, D->H and G->H calls. These combinations are not allowed by CUDA and we were reluctantly allowing them to work around device-side calls to math functions in std namespace. We no longer need it after r258880. Differential Revision: http://reviews.llvm.org/D16870 llvm-svn: 260697
-
Krzysztof Parzyszek authored
Rewrite the code to handle all pseudo-instructions in a single pass. This temporarily reverts spill slot optimization that used general- purpose registers to hold values of spilled predicate registers. llvm-svn: 260696
-
David Majnemer authored
For some cases, InstCombine replaces the sequence of xor/sub instruction followed by cmp instruction into a single cmp instruction. However, this replacement may result suboptimal result especially when the xor/sub has more than one use, as discussed in bug 26465 (https://llvm.org/bugs/show_bug.cgi?id=26465). This patch make the replacement happen only when xor/sub has only one use. Differential Revision: http://reviews.llvm.org/D16915 Patch by Taewook Oh! llvm-svn: 260695
-
Tom Stellard authored
Historically, AMD internal sp3 assembler has flat_store* addr, data format. To match existing code and to enable reuse, change LLVM definitions to match. Also update MC and CodeGen tests. Differential Revision: http://reviews.llvm.org/D16927 Patch by: Nikolay Haustov llvm-svn: 260694
-
Changpeng Fang authored
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
-
Krzysztof Parzyszek authored
This code is dead. The expansion is now done in HexagonFrameLowering. llvm-svn: 260691
-
Krzysztof Parzyszek authored
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
-
Geoff Berry authored
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
-
Krzysztof Parzyszek authored
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
-
- Feb 12, 2016
-
-
Chad Rosier authored
Machine model description by Dave Estes <cestes@codeaurora.org>. llvm-svn: 260686
-
Rafael Espindola authored
llvm-svn: 260685
-
Rafael Espindola authored
llvm-svn: 260683
-
Jun Bum Lim authored
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
-
Aaron Ballman authored
Expand the simplify boolean expression check to handle implicit conversion of integral types to bool and improve the handling of implicit conversion of member pointers to bool. Implicit conversion of member pointers are replaced with explicit comparisons to nullptr. Implicit conversions of integral types are replaced with explicit comparisons to 0. Patch by Richard Thomson. llvm-svn: 260681
-
Krzysztof Parzyszek authored
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: 260680
-
Daniel Sanders authored
There is now a default name_suffix ('default') which should appease the buildbot and reveal why this builder lacks a suffix. llvm-svn: 260679 -
Krzysztof Parzyszek authored
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
-
Adhemerval Zanella authored
This patch adds some TLS relocations and relaxations for AArch64. Some Global-Dynamic relocation are handled by optimizing them to Local-Exec (Initial-Exec is not yet supported). They are: - R_AARCH64_TLSDESC_ADR_PAGE21 - R_AARCH64_TLSDESC_LD64_LO12_NC - R_AARCH64_TLSDESC_ADD_LO12_NC - R_AARCH64_TLSDESC_CALL Also some Init-Exec is optimized to Local-Exec if possible. They are: - R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21 - R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC Finally some Local-Exec relocation are handled in relocateOne: - R_AARCH64_TLSLE_ADD_TPREL_HI12 - R_AARCH64_TLSLE_ADD_TPREL_LO12_NC This work is mainly for compiler bootstrap, where static binaries is showing good progress (although shared object still lacking support from both TLS aarch64 backend and some other issues). llvm-svn: 260677
-
Benjamin Kramer authored
Found by msan. llvm-svn: 260676
-
Olivier Goffart authored
Fix a crash while parsing this code: struct X { friend constexpr int foo(X*) { return 12; } static constexpr int j = foo(static_cast<X*>(nullptr)); }; Differential Revision: http://reviews.llvm.org/D16973 llvm-svn: 260675 -
Jonas Hahnfeld authored
For pragma omp taskwait the runtime is called from the task context. Therefore, the reentry frame information should be updated. The information should be available for both taskwait event calls; therefore, set before the first event and reset after the last event. Patch by Joachim Protze Differential Revision: http://reviews.llvm.org/D17145 llvm-svn: 260674
-
Hrvoje Varga authored
Differential Revision: http://reviews.llvm.org/D17192 llvm-svn: 260673
-
Daniel Sanders authored
There's no obvious reason it should fail in this way but it's the only change on the blamelist. I suspect stale lit*.cfg's from previous builds. llvm-svn: 260672
-
Anastasia Stulova authored
The library functions defined in the C99 standard headers are not available (OpenCL v1.2 s6.9.f). This change stops treating OpenCL builtin functions as standard C lib functions to eliminate warning messages about printf format string. Patch by Liu Yaxun (Sam)! Differential Revision: http://reviews.llvm.org/D16812 llvm-svn: 260671
-
Haojian Wu authored
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
-
Daniel Sanders authored
The lit test-suite containing the unit tests needs to be explicitly specified as an argument to lit.py since it is no longer discovered when the other tests are run (because they are one directory deeper). dfsan, lsan, and sanitizer_common don't show the same problem. llvm-svn: 260669
-
Chandler Carruth authored
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
-
Daniel Marjamaki authored
I added portability warnings when int results are casted to long. I forgot to handle uint, ulong and ulonglong. Tested on x86 and powerpc targets, hope it works now on all buildbots. llvm-svn: 260667
-
Chandler Carruth authored
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
-
Daniel Marjamaki authored
Reviewers: alexfh Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D17140 llvm-svn: 260665
-
Enrico Granata authored
The data formatters for NSArray, NSDictionary and (only partially) NSSet contain logic to inspect the objects without running code. However, they also contain fallback logic that - in cases where LLDB can't recognize the specific subclass - actually does run code in order to inspect those objects. The argument for this logic was that these data types are critical enough that the risk of getting it wrong is outweighed by the advantage of always providing accurate child information. Practical experience however shows that "po" - a code running data-inspection command - is quite frequently used, and not considered burdensome by users. As such, this makes the code-running fallback in the data formatters a risk that carries very little actual reward. Also, unlike the time this code was originally written, we now have accurate class information for Objective-C, and thus we are less likely to improperly identify classes. This commit removes support for the code-running fallback, and aligns the data formatters for NSArray, NSDictionary and NSSet to the general no-code-running behavior of other data formatters. While it is possible for us to add support for some subclasses that are now no longer covered by static inspection alone, this is beyond the scope of this commit. llvm-svn: 260664
-
Argyrios Kyrtzidis authored
llvm-svn: 260663
-