summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend
Commit message (Collapse)AuthorAgeFilesLines
...
* OpenCL: Defining __ENDIAN_LITTLE__ and fix target endiannessMatt Arsenault2016-09-071-0/+3
| | | | | | | | | OpenCL requires __ENDIAN_LITTLE__ be set for little endian targets. The default for targets was also apparently big endian, so AMDGPU was incorrectly reported as big endian. Set this from the triple so targets don't have another place to set the endianness. llvm-svn: 280787
* Add -fprofile-dir= to clang.Nick Lewycky2016-08-311-1/+2
| | | | | | | | | | | | | | | | | | | | | -fprofile-dir=path allows the user to specify where .gcda files should be emitted when the program is run. In particular, this is the first flag that causes the .gcno and .o files to have different paths, LLVM is extended to support this. -fprofile-dir= does not change the file name in the .gcno (and thus where lcov looks for the source) but it does change the name in the .gcda (and thus where the runtime library writes the .gcda file). It's different from a GCOV_PREFIX because a user can observe that the GCOV_PREFIX_STRIP will strip paths off of -fprofile-dir= but not off of a supplied GCOV_PREFIX. To implement this we split -coverage-file into -coverage-data-file and -coverage-notes-file to specify the two different names. The !llvm.gcov metadata node grows from a 2-element form {string coverage-file, node dbg.cu} to 3-elements, {string coverage-notes-file, string coverage-data-file, node dbg.cu}. In the 3-element form, the file name is already "mangled" with .gcno/.gcda suffixes, while the 2-element form left that to the middle end pass. llvm-svn: 280306
* Unrevert r280035 now that the clang-cl bug it exposed has been fixed byRichard Smith2016-08-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r280133. Original commit message: C++ Modules TS: driver support for building modules. This works as follows: we add --precompile to the existing gamut of options for specifying how far to go when compiling an input (-E, -c, -S, etc.). This flag specifies that an input is taken to the precompilation step and no further, and this can be specified when building a .pcm from a module interface or when building a .pch from a header file. The .cppm extension (and some related extensions) are implicitly recognized as C++ module interface files. If --precompile is /not/ specified, the file is compiled (via a .pcm) to a .o file containing the code for the module (and then potentially also assembled and linked, if -S, -c, etc. are not specified). We do not yet suppress the emission of object code for other users of the module interface, so for now this will only work if everything in the .cppm file has vague linkage. As with the existing support for module-map modules, prebuilt modules can be provided as compiler inputs either via the -fmodule-file= command-line argument or via files named ModuleName.pcm in one of the directories specified via -fprebuilt-module-path=. This also exposes the -fmodules-ts cc1 flag in the driver. This is still experimental, and in particular, the concrete syntax is subject to change as the Modules TS evolves in the C++ committee. Unlike -fmodules, this flag does not enable support for implicitly loading module maps nor building modules via the module cache, but those features can be turned on separately and used in conjunction with the Modules TS support. llvm-svn: 280134
* Revert r280035 (and followups r280057, r280085), it caused PR30195Nico Weber2016-08-301-2/+0
| | | | llvm-svn: 280091
* This adds new options -fdenormal-fp-math and passes through option -ffast-mathSjoerd Meijer2016-08-301-0/+13
| | | | | | | | | | to CC1, which are translated to function attributes and can e.g. be mapped on build attributes FP_exceptions and FP_denormal. Setting these build attributes allows better selection of floating point libraries. Differential Revision: https://reviews.llvm.org/D23840 llvm-svn: 280064
* [sanitizer-coverage] add two more modes of instrumentation: trace-div and ↵Kostya Serebryany2016-08-301-0/+2
| | | | | | trace-gep, mostly usaful for value-profile-based fuzzing; clang part llvm-svn: 280044
* C++ Modules TS: driver support for building modules.Richard Smith2016-08-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This works as follows: we add --precompile to the existing gamut of options for specifying how far to go when compiling an input (-E, -c, -S, etc.). This flag specifies that an input is taken to the precompilation step and no further, and this can be specified when building a .pcm from a module interface or when building a .pch from a header file. The .cppm extension (and some related extensions) are implicitly recognized as C++ module interface files. If --precompile is /not/ specified, the file is compiled (via a .pcm) to a .o file containing the code for the module (and then potentially also assembled and linked, if -S, -c, etc. are not specified). We do not yet suppress the emission of object code for other users of the module interface, so for now this will only work if everything in the .cppm file has vague linkage. As with the existing support for module-map modules, prebuilt modules can be provided as compiler inputs either via the -fmodule-file= command-line argument or via files named ModuleName.pcm in one of the directories specified via -fprebuilt-module-path=. This also exposes the -fmodules-ts cc1 flag in the driver. This is still experimental, and in particular, the concrete syntax is subject to change as the Modules TS evolves in the C++ committee. Unlike -fmodules, this flag does not enable support for implicitly loading module maps nor building modules via the module cache, but those features can be turned on separately and used in conjunction with the Modules TS support. llvm-svn: 280035
* Add support for -fdiagnostics-absolute-paths: printing absolute paths in ↵Hans Wennborg2016-08-262-2/+20
| | | | | | | | diagnostics Differential Revision: https://reviews.llvm.org/D23816 llvm-svn: 279827
* C++ Modules TS: add frontend support for building pcm files from moduleRichard Smith2016-08-265-33/+57
| | | | | | | interface files. At the moment, all declarations (and no macros) are exported, and 'export' declarations are not supported yet. llvm-svn: 279794
* Refactor to remove the assumption that we know the name of the module we're ↵Richard Smith2016-08-253-4/+4
| | | | | | emitting at the point when we create a PCHGenerator (with the C++ modules TS, we find that out part way through parsing the input). llvm-svn: 279766
* PR29097: add an update record when we instantiate the default memberRichard Smith2016-08-241-0/+6
| | | | | | initializer of an imported field. llvm-svn: 279667
* DebugInfo: Add flag to CU to disable emission of inline debug info into the ↵David Blaikie2016-08-241-0/+1
| | | | | | | | | | skeleton CU In cases where .dwo/.dwp files are guaranteed to be available, skipping the extra online (in the .o file) inline info can save a substantial amount of space - see the original r221306 for more details there. llvm-svn: 279651
* Module: add -fprebuilt-module-path to support loading prebuilt modules.Manman Ren2016-08-184-10/+65
| | | | | | | | | | | | | In this mode, there is no need to load any module map and the programmer can simply use "@import" syntax to load the module directly from a prebuilt module path. When loading from prebuilt module path, we don't support rebuilding of the module files and we ignore compatible configuration mismatches. rdar://27290316 Differential Revision: http://reviews.llvm.org/D23125 llvm-svn: 279096
* Print the module format in clang -module-file-info.Adrian Prantl2016-08-171-2/+7
| | | | llvm-svn: 279005
* Support object-file-wrapped modules in clang -module-file-info.Adrian Prantl2016-08-171-0/+8
| | | | | | rdar://problem/24504815 llvm-svn: 279004
* PR18417: Increase -ftemplate-depth to the value 1024 recommended by the C++Richard Smith2016-08-171-1/+1
| | | | | | | | standard's Annex B. We now attempt to increase the process's stack rlimit to 8MiB on startup, which appears to be enough to allow this to work reliably. (And if it turns out not to be, we can investigate increasing it further.) llvm-svn: 278983
* [VFS] Add 'ignore-non-existent-contents' field to YAML filesBruno Cardoso Lopes2016-08-121-0/+4
| | | | | | | | | | | | | | | | | | Add 'ignore-non-existent-contents' to tell the VFS whether an invalid path obtained via 'external-contents' should cause iteration on the VFS to stop. If 'true', the VFS should ignore the entry and continue with the next. Allows YAML files to be shared across multiple compiler invocations regardless of prior existent paths in 'external-contents'. This global value is overridable on a per-file basis. This adds the parsing and write test part, but use by VFS comes next. Differential Revision: https://reviews.llvm.org/D23422 rdar://problem/27531549 llvm-svn: 278456
* [OpenCL] Handle -cl-fp32-correctly-rounded-divide-sqrtYaxun Liu2016-08-091-0/+2
| | | | | | | | Let the driver pass the option to frontend. Do not set precision metadata for division instructions when this option is set. Set function attribute "correctly-rounded-divide-sqrt-fp-math" based on this option. Differential Revision: https://reviews.llvm.org/D22940 llvm-svn: 278155
* [OpenCL][AMDGPU] Add support for -cl-denorms-are-zeroYaxun Liu2016-08-092-0/+4
| | | | | | | | | | | | Adjust target features for amdgcn target when -cl-denorms-are-zero is set. Denormal support is controlled by feature strings fp32-denormals fp64-denormals in amdgcn target. If -cl-denorms-are-zero is not set and the command line does not set fp32/64-denormals feature string, +fp32-denormals +fp64-denormals will be on for GPU's supporting them. A new virtual function virtual void TargetInfo::adjustTargetOptions(const CodeGenOptions &CGOpts, TargetOptions &TargetOpts) const is introduced to allow adjusting target option by codegen option. Differential Revision: https://reviews.llvm.org/D22815 llvm-svn: 278151
* [analyzer] Command line option to show enabled checker list.Gabor Horvath2016-08-081-0/+1
| | | | | | | | | | | | This patch adds a command line option to list the checkers that were enabled by analyzer-checker and not disabled by -analyzer-disable-checker. It can be very useful to debug long command lines when it is not immediately apparent which checkers are turned on and which checkers are turned off. Differential Revision: https://reviews.llvm.org/D23060 llvm-svn: 278006
* Move helpers into anonymous namespaces. NFC.Benjamin Kramer2016-08-061-1/+1
| | | | llvm-svn: 277918
* Reapply r276973 "Adjust Registry interface to not require plugins to export ↵John Brawn2016-08-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a registry" This differs from the previous version by being more careful about template instantiation/specialization in order to prevent errors when building with clang -Werror. Specifically: * begin is not defined in the template and is instead instantiated when Head is. I think the warning when we don't do that is wrong (PR28815) but for now at least do it this way to avoid the warning. * Instead of performing template specializations in LLVM_INSTANTIATE_REGISTRY instead provide a template definition then do explicit instantiation. No compiler I've tried has problems with doing it the other way, but strictly speaking it's not permitted by the C++ standard so better safe than sorry. Original commit message: Currently the Registry class contains the vestiges of a previous attempt to allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a plugin would have its own copy of a registry and export it to be imported by the tool that's loading the plugin. This only works if the plugin is entirely self-contained with the only interface between the plugin and tool being the registry, and in particular this conflicts with how IR pass plugins work. This patch changes things so that instead the add_node function of the registry is exported by the tool and then imported by the plugin, which solves this problem and also means that instead of every plugin having to export every registry they use instead LLVM only has to export the add_node functions. This allows plugins that use a registry to work on Windows if LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used. llvm-svn: 277806
* Initial vectorization support for svml calls (short vector math library).Matt Masten2016-07-291-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D19544 llvm-svn: 277167
* [OpenCL] Generate opaque type for sampler_t and function call for the ↵Yaxun Liu2016-07-281-0/+7
| | | | | | | | | | | | | | | | initializer Currently Clang use int32 to represent sampler_t, which have been a source of issue for some backends, because in some backends sampler_t cannot be represented by int32. They have to depend on kernel argument metadata and use IPA to find the sampler arguments and global variables and transform them to target specific sampler type. This patch uses opaque pointer type opencl.sampler_t* for sampler_t. For each use of file-scope sampler variable, it generates a function call of __translate_sampler_initializer. For each initialization of function-scope sampler variable, it generates a function call of __translate_sampler_initializer. Each builtin library can implement its own __translate_sampler_initializer(). Since the real sampler type tends to be architecture dependent, allowing it to be initialized by a library function simplifies backend design. A typical implementation of __translate_sampler_initializer could be a table lookup of real sampler literal values. Since its argument is always a literal, the returned pointer is known at compile time and easily optimized to finally become some literal values directly put into image read instructions. This patch is partially based on Alexey Sotkin's work in Khronos Clang (https://github.com/KhronosGroup/SPIR/commit/3d4eec61623502fc306e8c67c9868be2b136e42b). Differential Revision: https://reviews.llvm.org/D21567 llvm-svn: 277024
* Revert r276973 "Adjust Registry interface to not require plugins to export a ↵John Brawn2016-07-281-1/+1
| | | | | | | | | registry" Buildbot failures when building with clang -Werror. Reverting while I try to figure this out. llvm-svn: 277008
* Reapply r276856 "Adjust Registry interface to not require plugins to export ↵John Brawn2016-07-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | a registry" This version has two fixes compared to the original: * In Registry.h the template static members are instantiated before they are used, as clang gives an error if you do it the other way around. * The use of the Registry template in clang-tidy is updated in the same way as has been done everywhere else. Original commit message: Currently the Registry class contains the vestiges of a previous attempt to allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a plugin would have its own copy of a registry and export it to be imported by the tool that's loading the plugin. This only works if the plugin is entirely self-contained with the only interface between the plugin and tool being the registry, and in particular this conflicts with how IR pass plugins work. This patch changes things so that instead the add_node function of the registry is exported by the tool and then imported by the plugin, which solves this problem and also means that instead of every plugin having to export every registry they use instead LLVM only has to export the add_node functions. This allows plugins that use a registry to work on Windows if LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used. llvm-svn: 276973
* Add flags to toggle preservation of assembly commentsNirav Dave2016-07-271-0/+1
| | | | | | | | | | | | Summary: Add -fpreserve-as-comments and -fno-preserve-as-comments. Reviewers: echristo, rnk Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D22883 llvm-svn: 276907
* Revert r276856 "Adjust Registry interface to not require plugins to export a ↵John Brawn2016-07-271-1/+1
| | | | | | | | registry" This is causing a huge pile of buildbot failures. llvm-svn: 276857
* Adjust Registry interface to not require plugins to export a registryJohn Brawn2016-07-271-1/+1
| | | | | | | | | | | | | | | | | | | | Currently the Registry class contains the vestiges of a previous attempt to allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a plugin would have its own copy of a registry and export it to be imported by the tool that's loading the plugin. This only works if the plugin is entirely self-contained with the only interface between the plugin and tool being the registry, and in particular this conflicts with how IR pass plugins work. This patch changes things so that instead the add_node function of the registry is exported by the tool and then imported by the plugin, which solves this problem and also means that instead of every plugin having to export every registry they use instead LLVM only has to export the add_node functions. This allows plugins that use a registry to work on Windows if LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used. Differential Revision: http://reviews.llvm.org/D21385 llvm-svn: 276856
* Modules: add command line option fmodules-disable-diagnostic-validationManman Ren2016-07-262-2/+9
| | | | | | | | | | | | | | | | | | | | | | With PCH+Module, sometimes compiler gives a hard error: Module file ‘<some-file path>.pcm' is out of date and needs to be rebuilt This happens when we have a pch importing a module and the module gets overwritten by another compiler instance after we build the pch (one example is that both compiler instances hash to the same pcm file but use different diagnostic options). When we try to load the pch later on, the compiler notices that the imported module is out of date (modification date, size do not match) but it can't handle this out of date pcm (i.e it does not know how to rebuild the pch). This commit introduces a new command line option so for PCH + module, we can turn on this option and if two compiler instances only differ in diagnostic options, the latter instance will not invalidate the original pcm. rdar://26675801 Differential Revision: http://reviews.llvm.org/D22773 llvm-svn: 276769
* Add -fmodules-ts flag to cc1 for the provisional C++ modules TS, and markRichard Smith2016-07-231-2/+3
| | | | | | 'module' and 'import' as keywords when the flag is specified. llvm-svn: 276508
* Provide __GLIBCXX_TYPE_INT_N_0 and __GLIBCXX_BITSIZE_INT_N_0 when in C++ gnu ↵Yaron Keren2016-07-211-0/+5
| | | | | | | | | language extensions. These are used by libstdc++ <type_traits> for is_integral<__int128>. Addresses http://llvm.org/pr23156. llvm-svn: 276252
* [NFC] Header cleanupMehdi Amini2016-07-1819-31/+15
| | | | | | | | | | Summary: Removed unused headers, replaced some headers with forward class declarations Patch by: Eugene <claprix@yandex.ru> Differential Revision: https://reviews.llvm.org/D20100 llvm-svn: 275882
* Attempt to work around MSVC rejects-valid, round 2.Richard Smith2016-07-171-2/+5
| | | | llvm-svn: 275730
* PR28589: attempt to work around MSVC rejects-valid.Richard Smith2016-07-171-1/+2
| | | | llvm-svn: 275727
* Reimplement ExternalSemaSource delegation in terms ofRichard Smith2016-07-161-120/+36
| | | | | | | MultiplexExternalSemaSource to remove one of the places that needs updating every time the ExternalSemaSource interface changes. llvm-svn: 275653
* [CUDA][OpenMP] Create generic offload actionSamuel Antao2016-07-151-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch replaces the CUDA specific action by a generic offload action. The offload action may have multiple dependences classier in “host” and “device”. The way this generic offloading action is used is very similar to what is done today by the CUDA implementation: it is used to set a specific toolchain and architecture to its dependences during the generation of jobs. This patch also proposes propagating the offloading information through the action graph so that that information can be easily retrieved at any time during the generation of commands. This allows e.g. the "clang tool” to evaluate whether CUDA should be supported for the device or host and ptas to easily retrieve the target architecture. This is an example of how the action graphs would look like (compilation of a single CUDA file with two GPU architectures) ``` 0: input, "cudatests.cu", cuda, (host-cuda) 1: preprocessor, {0}, cuda-cpp-output, (host-cuda) 2: compiler, {1}, ir, (host-cuda) 3: input, "cudatests.cu", cuda, (device-cuda, sm_35) 4: preprocessor, {3}, cuda-cpp-output, (device-cuda, sm_35) 5: compiler, {4}, ir, (device-cuda, sm_35) 6: backend, {5}, assembler, (device-cuda, sm_35) 7: assembler, {6}, object, (device-cuda, sm_35) 8: offload, "device-cuda (nvptx64-nvidia-cuda:sm_35)" {7}, object 9: offload, "device-cuda (nvptx64-nvidia-cuda:sm_35)" {6}, assembler 10: input, "cudatests.cu", cuda, (device-cuda, sm_37) 11: preprocessor, {10}, cuda-cpp-output, (device-cuda, sm_37) 12: compiler, {11}, ir, (device-cuda, sm_37) 13: backend, {12}, assembler, (device-cuda, sm_37) 14: assembler, {13}, object, (device-cuda, sm_37) 15: offload, "device-cuda (nvptx64-nvidia-cuda:sm_37)" {14}, object 16: offload, "device-cuda (nvptx64-nvidia-cuda:sm_37)" {13}, assembler 17: linker, {8, 9, 15, 16}, cuda-fatbin, (device-cuda) 18: offload, "host-cuda (powerpc64le-unknown-linux-gnu)" {2}, "device-cuda (nvptx64-nvidia-cuda)" {17}, ir 19: backend, {18}, assembler 20: assembler, {19}, object 21: input, "cuda", object 22: input, "cudart", object 23: linker, {20, 21, 22}, image ``` The changes in this patch pass the existent regression tests (keeps the existent functionality) and resulting binaries execute correctly in a Power8+K40 machine. Reviewers: echristo, hfinkel, jlebar, ABataev, tra Subscribers: guansong, andreybokhanko, tcramer, mkuron, cfe-commits, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D18171 llvm-svn: 275645
* Frontend: Simplify ownership model for clang's output streams.Peter Collingbourne2016-07-159-97/+106
| | | | | | | | | | | | | | This changes the CompilerInstance::createOutputFile function to return a std::unique_ptr<llvm::raw_ostream>, rather than an llvm::raw_ostream implicitly owned by the CompilerInstance. This in most cases required that I move ownership of the output stream to the relevant ASTConsumer. The motivation for this change is to allow BackendConsumer to be a client of interfaces such as D20268 which take ownership of the output stream. Differential Revision: http://reviews.llvm.org/D21537 llvm-svn: 275507
* Add XRay flags to Clang. We implement two flags to control the XRay behaviour:Aaron Ballman2016-07-131-0/+3
| | | | | | | | | | | -fxray-instrument: enables XRay annotation of IR -fxray-instruction-threshold: configures the threshold for function size (looking at IR instructions), and allow LLVM to decide whether to add the nop sleds later on in the process. Also implements the related xray_always_instrument and xray_never_instrument function attributes. Patch by Dean Michael Berris. llvm-svn: 275330
* [OpenCL] Fixes failures in test/Driver/opencl.cl.Yaxun Liu2016-07-131-12/+12
| | | | | | | | | | Also fixes strict-aliasing option to only be allowed when OpenCL Version 1.0. Added testcase in test/Frontend/opencl-blocks.cl. Patch by Aaron En Ye Shi. Differential Revision: http://reviews.llvm.org/D22170 llvm-svn: 275318
* [PCH/preamble] Make sure that if the preamble/PCH was serialized with errors ↵Argyrios Kyrtzidis2016-07-132-2/+3
| | | | | | | | | | that we set diagnostic engine state appropriately. Otherwise there can be a crash with CFG analysis warnings doing work on invalid AST. Fixes crash of rdar://26224134 llvm-svn: 275313
* [PCH] Add a fno-pch-timestamp option to cc1 to disable inclusion of ↵Pierre Gousseau2016-07-132-1/+5
| | | | | | | | | | | | timestamps in PCH files. This is to allow distributed build systems, that do not preserve time stamps, to use PCH files. Second and last part of the patch proposed at: Differential Revision: http://reviews.llvm.org/D20867 llvm-svn: 275267
* [OpenCL] Add missing -cl-no-signed-zeros option into driverYaxun Liu2016-07-081-1/+2
| | | | | | | | | | | | Add OCL option -cl-no-signed-zeros to driver options. Also added to opencl.cl testcases. Patch by Aaron En Ye Shi. Differential Revision: http://reviews.llvm.org/D22067 llvm-svn: 274923
* Use arrays or initializer lists to feed ArrayRefs instead of SmallVector ↵Benjamin Kramer2016-07-021-3/+1
| | | | | | | | where possible. No functionality change intended llvm-svn: 274432
* [OpenMP] Use fopenmp prefix for all options introduced by the offloading ↵Samuel Antao2016-06-301-2/+2
| | | | | | | | | | | | | | implementation. Summary: This patch changes the options used by offloading to start with -fopenmp instead of -fomp. This makes the option naming more consistent and materializes a suggestion by Richard Smith in http://reviews.llvm.org/D9888. Reviewers: hfinkel, carlo.bertolli, arpith-jacob, ABataev Subscribers: kkwli0, cfe-commits, caomhin Differential Revision: http://reviews.llvm.org/D21841 llvm-svn: 274283
* [OpenCL] Allow -cl-std and other standard -cl- options in driverYaxun Liu2016-06-291-0/+13
| | | | | | | | | | | | Allow -cl-std and other standard -cl- options from cc1 to driver. Added a test for the options moved. Patch by Aaron En Ye Shi. Differential Revision: http://reviews.llvm.org/D21031 llvm-svn: 274150
* Avoid accessing an invalid PresumedLoc.Jordan Rose2016-06-281-1/+1
| | | | | | | | | | | | | | | | | | DiagnosticNoteRenderer asserts trying to emit its "while building module Foo imported from bar.h:5" note when the presumed location of the import is invalid. This assertion was added in r267914, where most uses of 'getFilename' were updated to test 'isValid' instead. This one must have been missed. I can't come up with a test because this location is always valid in C-based code, but external clients that manually import modules (*cough*Swift*cough*) sometimes provide invalid SourceLocations. rdar://problem/26099576 http://reviews.llvm.org/D21111 llvm-svn: 273976
* Frontend: clang-format a statement, NFCSaleem Abdulrasool2016-06-281-4/+4
| | | | llvm-svn: 273972
* Use even more ArrayRefsDavid Majnemer2016-06-241-6/+4
| | | | | | No functional change is intended, just a small refactoring. llvm-svn: 273650
* Use more ArrayRefsDavid Majnemer2016-06-243-7/+7
| | | | | | No functional change is intended, just a small refactoring. llvm-svn: 273647
OpenPOWER on IntegriCloud