- Dec 19, 2015
-
-
Rafael Espindola authored
An error that is pretty easy to make is to use the lazy bitcode reader and then do something like if (V.use_empty()) The problem is that uses in unmaterialized functions are not accounted for. This patch adds asserts that all uses are known. llvm-svn: 256105
-
Paul Robinson authored
Adds driver options named -glldb and -gsce to mean -g plus tuning for lldb and SCE debuggers respectively; the existing -ggdb option does the same for gdb. Existing options -ggdb0, -ggdb1 etc. unpack into -ggdb -g<N>. (There will not be -glldb<N> or -gsce<N> options.) The tuning gets a target-specific default in the driver, and is passed into cc1 with the new -debugger-tuning option. As fallout, fixes where '-gsplit-dwarf -g0' would ignore the -g0 part on Linux. Differential Revision: http://reviews.llvm.org/D15651 llvm-svn: 256104
-
Xinliang David Li authored
llvm-svn: 256103
-
JF Bastien authored
The test will mainly be useful to check that the .s file assembles and relocates properly because vtables reference functions in their data section. llvm-svn: 256102
-
Manuel Jacob authored
llvm-svn: 256101
-
Manuel Jacob authored
llvm-svn: 256100
-
Xinliang David Li authored
llvm-svn: 256099
-
Matt Arsenault authored
SDIV and UDIV had special handling, but this is the same handling that min/max need. llvm-svn: 256098
-
Vedant Kumar authored
llvm-svn: 256097
-
Vedant Kumar authored
llvm-svn: 256096
-
Vedant Kumar authored
Make personality functions, prefix data, and prologue data hungoff operands of Function. This is based on the email thread "[RFC] Clean up the way we store optional Function data" on llvm-dev. Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback! Includes a fix to scrub value subclass data in dropAllReferences. Does not use binary literals. Differential Revision: http://reviews.llvm.org/D13829 llvm-svn: 256095
-
Vedant Kumar authored
This reverts commit r256093. This broke lld-x86_64-win7 because of -Werror,-Wc++1y-extensions. llvm-svn: 256094
-
Vedant Kumar authored
Make personality functions, prefix data, and prologue data hungoff operands of Function. This is based on the email thread "[RFC] Clean up the way we store optional Function data" on llvm-dev. Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback! Includes a fix to scrub value subclass data in dropAllReferences. Differential Revision: http://reviews.llvm.org/D13829 llvm-svn: 256093
-
Xinliang David Li authored
Creator and lookup interfaces are added to this symtab class. The new interfaces will be used by InstrProf Readers and writer. A unit test is also added for the new APIs. llvm-svn: 256092
-
Vedant Kumar authored
This reverts commit r256090. This broke llvm-clang-lld-x86_64-debian-fast. llvm-svn: 256091
-
Vedant Kumar authored
Make personality functions, prefix data, and prologue data hungoff operands of Function. This is based on the email thread "[RFC] Clean up the way we store optional Function data" on llvm-dev. Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback! Differential Revision: http://reviews.llvm.org/D13829 llvm-svn: 256090
-
Simon Atanasyan authored
The patch configure ELF header flags for MIPS target. For now the flags are hard coded. In fact they depends on ELF flags of input object files and selected emulation. Differential Revision: http://reviews.llvm.org/D15575 llvm-svn: 256089
-
Chris Bieneman authored
This reverts commit r256069, which was an unintentional tag along on another commit. llvm-svn: 256088
-
Mehdi Amini authored
Follow-up to r256056. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 256087
-
Kostya Serebryany authored
llvm-svn: 256086
-
Kostya Serebryany authored
llvm-svn: 256085
-
Keno Fischer authored
llc_dwarf adds an mtriple, which forces this to use COFF, causing the test to fail. Hopefully using regular llc without the triple will work fine everywhere llvm-svn: 256084
-
Richard Smith authored
llvm-svn: 256083
-
Tom Stellard authored
Summary: The analysis of shader inputs was completely wrong. We were passing the wrong index to AttributeSet::hasAttribute() and the logic for which inputs where in SGPRs was wrong too. Reviewers: arsenm Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D15608 llvm-svn: 256082
-
Kostya Serebryany authored
llvm-svn: 256081
-
Richard Smith authored
llvm-svn: 256080
-
Philip Reames authored
As shown by the included test case, it's reasonable to end up with constant references during base pointer calculation. The code actually handled this case just fine, we only had the assert to help isolate problems under the belief that constant references shouldn't be present in IR generated by managed frontends. This turned out to be wrong on two fronts: 1) Manual Jacobs is working on a language with constant references, and b) we found a case where the optimizer does create them in practice. llvm-svn: 256079
-
Paul Robinson authored
Reapplies r256063, except instead of frugally re-using an LLVM enum, we define a Clang enum, to avoid exposing too much LLVM interface. Differential Revision: http://reviews.llvm.org/D15650 llvm-svn: 256078
-
Keno Fischer authored
Summary: First up is instcombine, where in the dbg.declare -> dbg.value conversion, the llvm.dbg.value needs to be called on the actual loaded value, rather than the address (since the whole point of this transformation is to be able to get rid of the alloca). Further, now that that's cleaned up, we can remove a hack in the backend, that would add an implicit OP_deref if the argument to dbg.value was an alloca. This stems from before the existence of DIExpression and is no longer necessary since the deref can be expressed explicitly. Now, in order to make sure that the tests pass with this change, we need to correct the printing of DEBUG_VALUE comments to take into account the expression, which wasn't taken into account before. Unfortunately, for both these changes, there were a number of incorrect test cases (mostly the wrong number of DW_OP_derefs, but also a couple where the test itself was broken more badly). aprantl and I have gone through and adjusted these test case in order to make them pass with these fixes and in some cases to make sure they're actually testing what they are meant to test. Reviewers: aprantl Subscribers: dsanders Differential Revision: http://reviews.llvm.org/D14186 llvm-svn: 256077
-
Eric Christopher authored
feature for command line compatibility. llvm-svn: 256076
-
Matt Arsenault authored
noduplicate prevents unrolling of small loops that happen to have barriers in them. If a loop has a barrier in it, it is OK to duplicate it for the unroll. llvm-svn: 256075
-
Matt Arsenault authored
This was using an anyext when promoting the type when zext/sext is required. llvm-svn: 256074
-
Nicolai Haehnle authored
Reviewers: arsenm, tstellarAMD Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D15629 llvm-svn: 256073
-
Nicolai Haehnle authored
Summary: When copying aggregate registers within the same register class, there may be an overlap between source and destination that forces us to do the copy backwards. Do the simplest possible thing that guarantees the correct order of moves when there are overlaps, and does whatever when there is no overlap. (The last part forces some trivial adjustments to test cases.) Together with r255906, this fixes a VM fault in Unreal Elemental Demo. While at it, change the generation of kill and def flags to something that looks more reasonable. This method is used very late during compilation, so it probably doesn't matter in practice, and to be honest, I don't know if this change is actually correct because the semantics in connection with aggregate registers vs. sub-registers are not clear to me. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93264 Reviewers: arsenm, tstellarAMD Subscribers: arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D15622 llvm-svn: 256072
-
Kostya Serebryany authored
llvm-svn: 256071
-
Chris Bieneman authored
Turns out cc1's flag has 1 - not 2... llvm-svn: 256070
-
Chris Bieneman authored
Summary: This patch adds support for the clang multi-stage bootstrapping to support PGO profdata generation, and can build a 2 or 3 stage compiler. With this patch applied you can configure your build directory with the following invocation of CMake: cmake -G <generator> -C <path_to_clang>/cmake/caches/PGO.cmake <source dir> After configuration the following additional targets will be generated: stage2-instrumented: Builds a stage1 x86 compiler, runtime, and required tools (llvm-config, llvm-profdata) then uses that compiler to build an instrumented stage2 compiler. stage2-instrumented-generate-profdata: Depends on "stage2-instrumented" and will use the instrumented compiler to generate profdata based on the training files in <clang>/utils/perf-training stage2: Depends on "stage2-instrumented-generate-profdata" and will use the stage1 compiler with the stage2 profdata to build a PGO-optimized compiler. stage2-check-llvm: Depends on stage2 and runs check-llvm using the stage3 compiler. stage2-check-clang: Depends on stage2 and runs check-clang using the stage3 compiler. stage2-check-all: Depends on stage2 and runs check-all using the stage3 compiler. stage2-test-suite: Depends on stage2 and runs the test-suite using the stage3 compiler (requires in-tree test-suite). Reviewers: bogner, silvas, chandlerc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D15584 llvm-svn: 256069
-
James Y Knight authored
I don't have any way to test MSVC compilation, but maybe this will fix the error: llvm/Support/TrailingObjects.h(286) : error C3210: 'TrailingObjectsBase' : access declaration can only be applied to a base class member llvm/Support/TrailingObjects.h(337) : see reference to class template instantiation 'llvm::TrailingObjects<BaseTy,TrailingTys...>' being compiled llvm/Support/TrailingObjects.h(286) : error C2602: 'llvm::trailing_objects_internal::TrailingObjectsBase::OverloadToken' is not a member of a base class of 'llvm::TrailingObjects<BaseTy,TrailingTys...>' llvm/Support/TrailingObjects.h(91) : see declaration of 'llvm::trailing_objects_internal::TrailingObjectsBase::OverloadToken' llvm-svn: 256068
-
Siva Chandra authored
Summary: Also xfailed for GCC as there is an problem with debug info generation. Reviewers: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D15657 llvm-svn: 256067
-
Paul Robinson authored
llvm-svn: 256066
-