summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR
Commit message (Collapse)AuthorAgeFilesLines
...
* Make Function::getInstructionCount constMircea Trofin2018-10-181-2/+2
| | | | | | | | | | | | | | Summary: Function::getInstructionCount can be const. Reviewers: davidxl, paquette Reviewed By: davidxl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D53378 llvm-svn: 344754
* [Intrinsic] Signed Saturation Addition IntrinsicLeonard Chan2018-10-161-0/+9
| | | | | | | | | | | Add an intrinsic that takes 2 integers and perform saturation addition on them. This is a part of implementing fixed point arithmetic in clang where some of the more complex operations will be implemented as intrinsics. Differential Revision: https://reviews.llvm.org/D53053 llvm-svn: 344629
* [TI removal] Make `getTerminator()` return a generic `Instruction`.Chandler Carruth2018-10-151-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | This removes the primary remaining API producing `TerminatorInst` which will reduce the rate at which code is introduced trying to use it and generally make it much easier to remove the remaining APIs across the codebase. Also clean up some of the stragglers that the previous mechanical update of variables missed. Users of LLVM and out-of-tree code generally will need to update any explicit variable types to handle this. Replacing `TerminatorInst` with `Instruction` (or `auto`) almost always works. Most of these edits were made in prior commits using the perl one-liner: ``` perl -i -ple 's/TerminatorInst(\b.* = .*getTerminator\(\))/Instruction\1/g' ``` This also my break some rare use cases where people overload for both `Instruction` and `TerminatorInst`, but these should be easily fixed by removing the `TerminatorInst` overload. llvm-svn: 344504
* [TI removal] Rework `InstVisitor` to support visiting instructions thatChandler Carruth2018-10-151-16/+16
| | | | | | | | | are terminators without relying on the specific `TerminatorInst` type. This required cleaning up two users of `InstVisitor`s usage of `TerminatorInst` as well. llvm-svn: 344503
* [TI removal] Make variables declared as `TerminatorInst` and initializedChandler Carruth2018-10-154-5/+5
| | | | | | | | | | | | | by `getTerminator()` calls instead be declared as `Instruction`. This is the biggest remaining chunk of the usage of `getTerminator()` that insists on the narrow type and so is an easy batch of updates. Several files saw more extensive updates where this would cascade to requiring API updates within the file to use `Instruction` instead of `TerminatorInst`. All of these were trivial in nature (pervasively using `Instruction` instead just worked). llvm-svn: 344502
* Generalize an IR verifier check to work with non-zero program address spacesDylan McKay2018-10-111-1/+2
| | | | | | | | | | | | | | | This commit modifies an existing IR verifier check that assumes all functions will be located in the default address space 0. Rather than using the default paramater value getPointerTo(AddrSpace=0), explicitly specify the program memory address space from the data layout. This only affects targets that specify a nonzero address space in their data layouts. The only in-tree target that does this is AVR. llvm-svn: 344243
* llvm-c: Add C APIs to access DebugLoc infoSaleem Abdulrasool2018-10-101-0/+73
| | | | | | | Add thin shims to C interface to provide access to DebugLoc info for Instructions, GlobalVariables and Functions. Patch by Josh Berdine! llvm-svn: 344202
* [IRBuilder] Fixup CreateIntrinsic to allow specifying Types to Mangle.Neil Henning2018-10-081-12/+13
| | | | | | | | | | | | | | | | | | | | The IRBuilder CreateIntrinsic method wouldn't allow you to specify the types that you wanted the intrinsic to be mangled with. To fix this I've: - Added an ArrayRef<Type *> member to both CreateIntrinsic overloads. - Used that array to pass into the Intrinsic::getDeclaration call. - Added a CreateUnaryIntrinsic to replace the most common use of CreateIntrinsic where the type was auto-deduced from operand 0. - Added a bunch more unit tests to test Create*Intrinsic calls that weren't being tested (including the FMF flag that wasn't checked). This was suggested as part of the AMDGPU specific atomic optimizer review (https://reviews.llvm.org/D51969). Differential Revision: https://reviews.llvm.org/D52087 llvm-svn: 343962
* [InstCombine] Fix incongruous GEP type addrspaceEwan Crawford2018-10-081-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently running the @insertelem_after_gep function below through the InstCombine pass with opt produces invalid IR. Input: ``` define void @insertelem_after_gep(<16 x i32>* %t0) { %t1 = bitcast <16 x i32>* %t0 to [16 x i32]* %t2 = addrspacecast [16 x i32]* %t1 to [16 x i32] addrspace(3)* %t3 = getelementptr inbounds [16 x i32], [16 x i32] addrspace(3)* %t2, i64 0, i64 0 %t4 = insertelement <16 x i32 addrspace(3)*> undef, i32 addrspace(3)* %t3, i32 0 call void @extern_vec_pointers_func(<16 x i32 addrspace(3)*> %t4) ret void } ``` Output: ``` define void @insertelem_after_gep(<16 x i32>* %t0) { %t3 = getelementptr inbounds <16 x i32>, <16 x i32>* %t0, i64 0, i64 0 %t4 = insertelement <16 x i32 addrspace(3)*> undef, i32 addrspace(3)* %t3, i32 0 call void @my_extern_func(<16 x i32 addrspace(3)*> %t4) ret void } ``` Which although causes no complaints when produced, isn't valid IR as the insertelement use of the %t3 GEP expects an address space. ``` opt: /tmp/bad.ll:52:73: error: '%t3' defined with type 'i32*' but expected 'i32 addrspace(3)*' %t4 = insertelement <16 x i32 addrspace(3)*> undef, i32 addrspace(3)* %t3, i32 0 ``` I've fixed this by adding an addrspacecast after the GEP in the InstCombine pass, and including a check for this type mismatch to the verifier. Reviewers: spatel, lebedev.ri Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52294 llvm-svn: 343956
* [New PM][PassTiming] implement -time-passes for the new pass managerFedor Sergeev2018-10-051-1/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enable time-passes functionality through PassInstrumentation callbacks for passes and analyses. TimePassesHandler class keeps all the callbacks, the timing data as it is being collected as well as the stack of currently active timers. Parts of the fix that might be somewhat unobvious: - mapping of passes into Timer (TimingData) can not be done per-instance. PassID name provided into the callback is common for all the pass invocations. Thus the only way to get a timing with reasonable granularity is to collect timing data per pass invocation, getting a new timer for each BeforePass. Hence the key for TimingData uses a pair of <StringRef/unsigned count> to uniquely identify a pass invocation. - consequently, this new-pass-manager implementation performs no aggregation of timing data, reporting timings for each pass invocation separately. In that it differs from legacy-pass-manager time-passes implementation that reports timing data aggregated per pass instance. - pass managers and adaptors are not tracked, similar to how pass managers are not tracked in legacy time-passes. - TimerStack tracks timers that are active, each BeforePass pushes the new timer on stack, each AfterPass pops active timer from stack and stops it. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D51276 llvm-svn: 343898
* [DebugInfo] Add support for DWARF5 call site-related attributesVedant Kumar2018-10-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DWARF v5 introduces DW_AT_call_all_calls, a subprogram attribute which indicates that all calls (both regular and tail) within the subprogram have call site entries. The information within these call site entries can be used by a debugger to populate backtraces with synthetic tail call frames. Tail calling frames go missing in backtraces because the frame of the caller is reused by the callee. Call site entries allow a debugger to reconstruct a sequence of (tail) calls which led from one function to another. This improves backtrace quality. There are limitations: tail recursion isn't handled, variables within synthetic frames may not survive to be inspected, etc. This approach is not novel, see: https://gcc.gnu.org/wiki/summit2010?action=AttachFile&do=get&target=jelinek.pdf This patch adds an IR-level flag (DIFlagAllCallsDescribed) which lowers to DW_AT_call_all_calls. It adds the minimal amount of DWARF generation support needed to emit standards-compliant call site entries. For easier deployment, when the debugger tuning is LLDB, the DWARF requirement is adjusted to v4. Testing: Apart from check-{llvm, clang}, I built a stage2 RelWithDebInfo clang binary. Its dSYM passed verification and grew by 1.4% compared to the baseline. 151,879 call site entries were added. rdar://42001377 Differential Revision: https://reviews.llvm.org/D49887 llvm-svn: 343883
* [PassTimingInfo] cleanup on TimingData's Timer handlingFedor Sergeev2018-10-041-6/+6
| | | | | | | | Replacing Timer* with unique_ptr<Timer> in a pass-to-timer map. That allows to get rid of unpretty raw deletes in PassTimingInfo destructor. Strictly cleanup, not intended to change any visible behavior. llvm-svn: 343772
* Emit template type and value parameter DIEs for template variables.Matthew Voss2018-10-035-49/+47
| | | | | | | | | | | | | | | | | | | Summary: Ensure the TemplateParam attribute of the DIGlobalVariable node is translated into the proper DIEs. Resolves https://bugs.llvm.org/show_bug.cgi?id=22119 Reviewers: dblaikie, probinson, aprantl, JDevlieghere, clayborg, whitequark, deadalnix Reviewed By: dblaikie Subscribers: llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D52057 llvm-svn: 343706
* Add atomicrmw operation to error messagesMatt Arsenault2018-10-031-3/+5
| | | | llvm-svn: 343656
* IR: Move AtomicRMW string names into classMatt Arsenault2018-10-022-19/+32
| | | | | | This will be used to improve error messages in a future commit. llvm-svn: 343647
* [LLVM-C] Add an accessor for the kind of a Metadata NodeRobert Widmann2018-10-011-0/+11
| | | | | | | | | | | | | | Summary: Allows for retrieving the type of a metadata node. Has the added benefit of ensuring that the C and C++ kind APIs stay in sync as a failure to add a corresponding LLVMMetadataKind will result in the switch in the accessor being semantically malformed. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52693 llvm-svn: 343469
* [LLVM-C] Add an accessor for the "value type" of a globalRobert Widmann2018-09-281-0/+4
| | | | | | | | | | | | | | Summary: Before this, there was no reasonable way to retrieve the type of a global value (most notably, a function) that was created with the C API. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52659 llvm-svn: 343363
* [LLVM-C] Fix broken build botsRobert Widmann2018-09-281-25/+25
| | | | | | | | | | | | Summary: Fix broken bots caused by the merge of D51522. Reviewers: whitequark Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52657 llvm-svn: 343334
* [LLVM-C] Add more debug information accessors to GlobalObject and InstructionRobert Widmann2018-09-281-0/+75
| | | | | | | | | | | | | | Summary: Adds missing debug information accessors to GlobalObject. This puts the finishing touches on cloning debug info in the echo tests. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: aprantl, JDevlieghere, llvm-commits, harlanhaskins Differential Revision: https://reviews.llvm.org/D51522 llvm-svn: 343330
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-274-6/+6
| | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D52573 llvm-svn: 343163
* [PassTiming] cleaning up legacy PassTimingInfo interface. NFCI.Fedor Sergeev2018-09-261-51/+60
| | | | | | | | | | | | | | | | | | | | During D51276 discussion it was decided that legacy PassTimingInfo interface can not be reused for new pass manager's implementation of -time-passes. This is a cleanup in preparation for D51276 to make legacy interface as concise as possible, moving the PassTimingInfo from the header into the anonymous legacy namespace in .cpp. It is rather close to a revert of rL340872 in a sense that it hides the interface and gets rid of templates. However as compared to a complete revert it resides in a different translation unit and has an additional pass-instance counting funcitonality (PassIDCountMap). Reviewers: philip.pfaffe Differential Revision: https://reviews.llvm.org/D52356 llvm-svn: 343104
* [ThinLTO] Efficiency fix for writing type id records in per-module indexesTeresa Johnson2018-09-251-20/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In D49565/r337503, the type id record writing was fixed so that only referenced type ids were emitted into each per-module index for ThinLTO distributed builds. However, this still left an efficiency issue: each per-module index checked all type ids for membership in the referenced set, yielding O(M*N) performance (M indexes and N type ids). Change the TypeIdMap in the summary to be indexed by GUID, to facilitate correlating with type identifier GUIDs referenced in the function summary TypeIdInfo structures. This allowed simplifying other places where a map from type id GUID to type id map entry was previously being used to aid this correlation. Also fix AsmWriter code to handle the rare case of type id GUID collision. For a large internal application, this reduced the thin link time by almost 15%. Reviewers: pcc, vitalybuka Subscribers: mehdi_amini, inglorion, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D51330 llvm-svn: 343021
* [New PM][PassInstrumentation] IR printing support for New Pass ManagerFedor Sergeev2018-09-241-12/+16
| | | | | | | | | | | | | | | | Implementing -print-before-all/-print-after-all/-filter-print-func support through PassInstrumentation callbacks. - PrintIR routines implement printing callbacks. - StandardInstrumentations class provides a central place to manage all the "standard" in-tree pass instrumentations. Currently it registers PrintIR callbacks. Reviewers: chandlerc, paquette, philip.pfaffe Differential Revision: https://reviews.llvm.org/D50923 llvm-svn: 342896
* Pass code-model through Module IR to LTO which will use it.Caroline Tice2018-09-211-0/+19
| | | | | | | | | | | Currently the code-model does not get saved in the module IR, so if a code model is specified when compiling with LTO, it gets lost and is not propagated properly to LTO. This patch, along with one for the front end, fixes that. Differential Revision: https://reviews.llvm.org/D52322 llvm-svn: 342760
* [New PM] Introducing PassInstrumentation frameworkFedor Sergeev2018-09-202-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pass Execution Instrumentation interface enables customizable instrumentation of pass execution, as per "RFC: Pass Execution Instrumentation interface" posted 06/07/2018 on llvm-dev@ The intent is to provide a common machinery to implement all the pass-execution-debugging features like print-before/after, opt-bisect, time-passes etc. Here we get a basic implementation consisting of: * PassInstrumentationCallbacks class that handles registration of callbacks and access to them. * PassInstrumentation class that handles instrumentation-point interfaces that call into PassInstrumentationCallbacks. * Callbacks accept StringRef which is just a name of the Pass right now. There were some ideas to pass an opaque wrapper for the pointer to pass instance, however it appears that pointer does not actually identify the instance (adaptors and managers might have the same address with the pass they govern). Hence it was decided to go simple for now and then later decide on what the proper mental model of identifying a "pass in a phase of pipeline" is. * Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies on different IRUnits (e.g. Analyses). * PassInstrumentationAnalysis analysis is explicitly requested from PassManager through usual AnalysisManager::getResult. All pass managers were updated to run that to get PassInstrumentation object for instrumentation calls. * Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra args out of a generic PassManager's extra args. This is the only way I was able to explicitly run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or RepeatedPass::run. TODO: Upon lengthy discussions we agreed to accept this as an initial implementation and then get rid of getAnalysisResult by improving RepeatedPass implementation. * PassBuilder takes PassInstrumentationCallbacks object to pass it further into PassInstrumentationAnalysis. Callbacks registration should be performed directly through PassInstrumentationCallbacks. * new-pm tests updated to account for PassInstrumentationAnalysis being run * Added PassInstrumentation tests to PassBuilderCallbacks unit tests. Other unit tests updated with registration of the now-required PassInstrumentationAnalysis. Made getName helper to return std::string (instead of StringRef initially) to fix asan builtbot failures on CGSCC tests. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D47858 llvm-svn: 342664
* [IR] add shuffle query for vector concatenationSanjay Patel2018-09-201-0/+17
| | | | | | This can be used for combining and in the vectorizers/cost models. llvm-svn: 342653
* [IR] Add a boolean field in DILocation to know if a line must covered or notCalixte Denizet2018-09-204-15/+36
| | | | | | | | | | | | | | | | | | | | | Summary: Some lines have a hit counter where they should not have one. For example, in C++, some cleanup is adding at the end of a scope represented by a '}'. So such a line has a hit counter where a user expects to not have one. The goal of the patch is to add this information in DILocation which is used to get the covered lines in GCOVProfiling.cpp. A following patch in clang will add this information when generating IR (https://reviews.llvm.org/D49916). Reviewers: marco-c, davidxl, vsk, javed.absar, rnk Reviewed By: rnk Subscribers: eraman, xur, danielcdh, aprantl, rnk, dblaikie, #debug-info, vsk, llvm-commits, sylvestre.ledru Tags: #debug-info Differential Revision: https://reviews.llvm.org/D49915 llvm-svn: 342631
* Temporarily Revert "[New PM] Introducing PassInstrumentation framework"Eric Christopher2018-09-202-23/+0
| | | | | | | | as it was causing failures in the asan buildbot. This reverts commit r342597. llvm-svn: 342616
* [New PM] Introducing PassInstrumentation frameworkFedor Sergeev2018-09-192-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pass Execution Instrumentation interface enables customizable instrumentation of pass execution, as per "RFC: Pass Execution Instrumentation interface" posted 06/07/2018 on llvm-dev@ The intent is to provide a common machinery to implement all the pass-execution-debugging features like print-before/after, opt-bisect, time-passes etc. Here we get a basic implementation consisting of: * PassInstrumentationCallbacks class that handles registration of callbacks and access to them. * PassInstrumentation class that handles instrumentation-point interfaces that call into PassInstrumentationCallbacks. * Callbacks accept StringRef which is just a name of the Pass right now. There were some ideas to pass an opaque wrapper for the pointer to pass instance, however it appears that pointer does not actually identify the instance (adaptors and managers might have the same address with the pass they govern). Hence it was decided to go simple for now and then later decide on what the proper mental model of identifying a "pass in a phase of pipeline" is. * Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies on different IRUnits (e.g. Analyses). * PassInstrumentationAnalysis analysis is explicitly requested from PassManager through usual AnalysisManager::getResult. All pass managers were updated to run that to get PassInstrumentation object for instrumentation calls. * Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra args out of a generic PassManager's extra args. This is the only way I was able to explicitly run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or RepeatedPass::run. TODO: Upon lengthy discussions we agreed to accept this as an initial implementation and then get rid of getAnalysisResult by improving RepeatedPass implementation. * PassBuilder takes PassInstrumentationCallbacks object to pass it further into PassInstrumentationAnalysis. Callbacks registration should be performed directly through PassInstrumentationCallbacks. * new-pm tests updated to account for PassInstrumentationAnalysis being run * Added PassInstrumentation tests to PassBuilderCallbacks unit tests. Other unit tests updated with registration of the now-required PassInstrumentationAnalysis. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D47858 llvm-svn: 342597
* Revert rL342544: [New PM] Introducing PassInstrumentation frameworkFedor Sergeev2018-09-192-23/+0
| | | | | | A bunch of bots fail to compile unittests. Reverting. llvm-svn: 342552
* [New PM] Introducing PassInstrumentation frameworkFedor Sergeev2018-09-192-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Pass Execution Instrumentation interface enables customizable instrumentation of pass execution, as per "RFC: Pass Execution Instrumentation interface" posted 06/07/2018 on llvm-dev@ The intent is to provide a common machinery to implement all the pass-execution-debugging features like print-before/after, opt-bisect, time-passes etc. Here we get a basic implementation consisting of: * PassInstrumentationCallbacks class that handles registration of callbacks and access to them. * PassInstrumentation class that handles instrumentation-point interfaces that call into PassInstrumentationCallbacks. * Callbacks accept StringRef which is just a name of the Pass right now. There were some ideas to pass an opaque wrapper for the pointer to pass instance, however it appears that pointer does not actually identify the instance (adaptors and managers might have the same address with the pass they govern). Hence it was decided to go simple for now and then later decide on what the proper mental model of identifying a "pass in a phase of pipeline" is. * Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies on different IRUnits (e.g. Analyses). * PassInstrumentationAnalysis analysis is explicitly requested from PassManager through usual AnalysisManager::getResult. All pass managers were updated to run that to get PassInstrumentation object for instrumentation calls. * Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra args out of a generic PassManager's extra args. This is the only way I was able to explicitly run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or RepeatedPass::run. TODO: Upon lengthy discussions we agreed to accept this as an initial implementation and then get rid of getAnalysisResult by improving RepeatedPass implementation. * PassBuilder takes PassInstrumentationCallbacks object to pass it further into PassInstrumentationAnalysis. Callbacks registration should be performed directly through PassInstrumentationCallbacks. * new-pm tests updated to account for PassInstrumentationAnalysis being run * Added PassInstrumentation tests to PassBuilderCallbacks unit tests. Other unit tests updated with registration of the now-required PassInstrumentationAnalysis. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D47858 llvm-svn: 342544
* [LLVM-C][OCaml] Add C and OCaml APIs for llvm::StructType::isLiteralwhitequark2018-09-181-0/+4
| | | | | | | | | | | | | | | | | Summary: This patch adds LLVMIsLiteralStruct to the C API to expose StructType::isLiteral. This is then used to implement the analogous addition to the OCaml API. Reviewers: whitequark, deadalnix Reviewed By: whitequark Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52209 llvm-svn: 342435
* [LLVM-C] Add support for ConstantExpr in LLVMGetNumIndices and LLVMGetIndiceswhitequark2018-09-181-0/+4
| | | | | | | | | | | | | | | | Summary: ConstantExpr supports getIndices, but prior to this patch LLVMGetNumIndices and LLVMGetIndices would error on them. Reviewers: whitequark Reviewed By: whitequark Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52206 llvm-svn: 342434
* fix 80-column violation with clang-formatAdrian Prantl2018-09-121-7/+4
| | | | llvm-svn: 342094
* [AArch64] Add parsing of aarch64_vector_pcs attribute.Sander de Smalen2018-09-121-0/+1
| | | | | | | | | | | | | | | | | | | This patch adds parsing support for the 'aarch64_vector_pcs' calling convention attribute to calls and function declarations. More information describing the vector ABI and procedure call standard can be found here: https://developer.arm.com/products/software-development-tools/\ hpc/arm-compiler-for-hpc/vector-function-abi Reviewers: t.p.northover, rnk, rengolin, javed.absar, thegameg, SjoerdMeijer Reviewed By: SjoerdMeijer Differential Revision: https://reviews.llvm.org/D51477 llvm-svn: 342030
* Add some context to fatal verifier errorsXin Tong2018-09-111-2/+3
| | | | | | | | | | | | | | | | Summary: Add function name when verification fails as an initial breadcrumb for debugging. Patch by David Callahan. Reviewers: mehdi_amini, modocache Reviewed By: modocache Subscribers: llvm-commits, modocache Differential Revision: https://reviews.llvm.org/D51386 llvm-svn: 341974
* Remove addBlockByrefAddress(), it is dead code as far as clang is concerned.Adrian Prantl2018-09-081-0/+8
| | | | | | | | | | | | This patch removes addBlockByrefAddress(), it is dead code as far as clang is concerned: Every byref block capture is emitted with a complex expression that is equivalent to what this function does. rdar://problem/31629055 Differential Revision: https://reviews.llvm.org/D51763 llvm-svn: 341737
* [X86] Modify the the rdtscp intrinsic to return values instead of taking a ↵Craig Topper2018-09-071-0/+37
| | | | | | | | | | pointer argument Similar to what was recently done for addcarry/subborrow and has been done for rdrand/rdseed for a while. It's better to use two results and an explicit store in IR when the store isn't part of the semantics of the instruction. This allows store->load forwarding to happen in the middle end. Or the store to be removed if its never loaded. Differential Revision: https://reviews.llvm.org/D51803 llvm-svn: 341698
* [X86] Change the addcarry and subborrow intrinsics to return 2 results and ↵Craig Topper2018-09-071-0/+58
| | | | | | | | | | remove the pointer argument. We should represent the store directly in IR instead. This gives the middle end a chance to remove it if it can see a load from the same address. Differential Revision: https://reviews.llvm.org/D51769 llvm-svn: 341677
* Output per-function size-info remarksJessica Paquette2018-09-061-12/+111
| | | | | | | | | | | This patch adds per-function size information remarks. Previously, passing -Rpass-analysis=size-info would only give you per-module changes. By adding the ability to do this per-function, it's easier to see which functions contributed the most to size changes. https://reviews.llvm.org/D51467 llvm-svn: 341588
* [SLC] Add an alignment to CreateGlobalStringDavid Green2018-09-061-0/+1
| | | | | | | | | | | | | | | | Previously the alignment on the newly created global strings was not set, meaning that DataLayout::getPreferredAlignment was free to overalign it to 16 bytes. This caused unnecessary code bloat with the padding between variables. The main example of this happening was the printf->puts optimisation in SimplifyLibCalls, but as the change here is made in IRBuilderBase::CreateGlobalString, other globals using this will now be aligned too. Differential Revision: https://reviews.llvm.org/D51410 llvm-svn: 341527
* [NFC] Improve clarity in emitInstrCountChangedRemarkJessica Paquette2018-09-041-1/+4
| | | | | | | | | Add a "CouldOnlyImpactOneFunction" bool that's true when we pass in a function. Just cleaning up a little bit, since I'm going to add in the per-function remarks soon from D51467. llvm-svn: 341407
* [x86/SLH] Add a real Clang flag and LLVM IR attribute for SpeculativeChandler Carruth2018-09-042-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Load Hardening. Wires up the existing pass to work with a proper IR attribute rather than just a hidden/internal flag. The internal flag continues to work for now, but I'll likely remove it soon. Most of the churn here is adding the IR attribute. I talked about this Kristof Beyls and he seemed at least initially OK with this direction. The idea of using a full attribute here is that we *do* expect at least some forms of this for other architectures. There isn't anything *inherently* x86-specific about this technique, just that we only have an implementation for x86 at the moment. While we could potentially expose this as a Clang-level attribute as well, that seems like a good question to defer for the moment as it isn't 100% clear whether that or some other programmer interface (or both?) would be best. We'll defer the programmer interface side of this for now, but at least get to the point where the feature can be enabled without relying on implementation details. This also allows us to do something that was really hard before: we can enable *just* the indirect call retpolines when using SLH. For x86, we don't have any other way to mitigate indirect calls. Other architectures may take a different approach of course, and none of this is surfaced to user-level flags. Differential Revision: https://reviews.llvm.org/D51157 llvm-svn: 341363
* [PassTiming] reporting time-passes separately for multiple pass instances of ↵Fedor Sergeev2018-09-041-12/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | the same pass Summary: Refactoring done by rL340872 accidentally appeared to be non-NFC, changing the way how multiple instances of the same pass are handled - aggregation of results by PassName forced data for multiple instances to be merged together and reported as one line. Getting back to creating/reporting timers per pass instance. Reporting was a bit enhanced by counting pass instances and adding #<num> suffix to the pass description. Note that it is instances that are being counted, not invocations of them. time-passes test updated to account for multiple passes being run. Reviewers: paquette, jhenderson, MatzeB, skatkov Reviewed By: skatkov Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51535 llvm-svn: 341346
* Fix typo in size remarks for module passesJessica Paquette2018-08-311-1/+1
| | | | | | | | | | | | | | | ModuleCount = InstrCount was incorrect. It should have been InstrCount = ModuleCount. This was making it emit an extra, incorrect remark for Print Module IR. The test didn't catch this, because it didn't ensure that the only remark output was from the desired pass. So, it was possible to have an extra remark come through and not fail. Updated the test so that we ensure that the last remark that's output comes from the desired pass. This is done by ensuring that whatever is being read after the last remark is YAML output rather than some incorrect garbage. llvm-svn: 341267
* [NFC] Optionally pass a function to emitInstrCountChangedRemarkJessica Paquette2018-08-311-14/+18
| | | | | | | | | In basic block, loop, and function passes, we already have a function that we can use to emit optimization remarks. We can use that instead of searching the module for the first suitable function (that is, one that contains at least one basic block.) llvm-svn: 341253
* [NFC] Check if P is a pass manager on entry to emitInstrCountChangedRemarkJessica Paquette2018-08-311-7/+7
| | | | | | | There's no point in finding a function to use for remark output when we're not going to emit anything. llvm-svn: 341252
* [NFC] Pass the instruction delta to emitInstrCountChangedRemarkJessica Paquette2018-08-311-19/+7
| | | | | | | | | | | | | | | Instead of counting the size of the entire module every time we run a pass, pass along a delta instead and use that to emit the remark. This means we only have to use (on average) smaller IR units to calculate instruction counts. E.g, in a BB pass, we only need to look at the delta of the BB instead of the delta of the entire module. 6/6 (This improved compile time for size remarks on sqlite3 + O2 significantly) llvm-svn: 341250
* [NFC] Pre-calculate module IR counts in size remarks.Jessica Paquette2018-08-311-5/+18
| | | | | | | | | | | | | | | Same as the previous NFC commits in the same vein. This one introduces a TODO. I'm going to change emitInstrCountChangedRemark so that it takes in a delta. Since the delta isn't necessary yet, it's not there. For now, this means that we're calculating the size of the module twice. Just done separately to keep the patches small. 4/6 llvm-svn: 341248
* [NFC] Pre-calculate basic block IR counts in size remarks.Jessica Paquette2018-08-311-6/+21
| | | | | | | | | | | Size remarks are slow due to lots of recalculation of the module. This is similar to the previous commit. Cache the size of the module and update counts in basic block passes based off a less-expensive delta. 2/6 llvm-svn: 341246
OpenPOWER on IntegriCloud