[llvm] r297505 - Fix all these headers to properly mark the doxygen comments.
Daniel Berlin via llvm-commits
llvm-commits at lists.llvm.org
Fri Mar 10 12:44:40 PST 2017
Author: dannyb
Date: Fri Mar 10 14:44:39 2017
New Revision: 297505
URL: http://llvm.org/viewvc/llvm-project?rev=297505&view=rev
Log:
Fix all these headers to properly mark the doxygen comments.
Modified:
llvm/trunk/include/llvm/Support/DebugCounter.h
llvm/trunk/include/llvm/Transforms/Utils/MemorySSA.h
llvm/trunk/include/llvm/Transforms/Utils/PredicateInfo.h
Modified: llvm/trunk/include/llvm/Support/DebugCounter.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Support/DebugCounter.h?rev=297505&r1=297504&r2=297505&view=diff
==============================================================================
--- llvm/trunk/include/llvm/Support/DebugCounter.h (original)
+++ llvm/trunk/include/llvm/Support/DebugCounter.h Fri Mar 10 14:44:39 2017
@@ -6,37 +6,40 @@
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
-// \file This file provides an implementation of debug counters. Debug counters
-// are a tool that let you narrow down a miscompilation to a specific thing
-// happening. To give a use case: Imagine you have a file, very large, and you
-// are trying to understand the minimal transformation that breaks it. Bugpoint
-// and bisection is often helpful here in narrowing it down to a specific pass,
-// but it's still a very large file, and a very complicated pass to try to
-// debug. That is where debug counting steps in. You can instrument the pass
-// with a debug counter before it does a certain thing, and depending on the
-// counts, it will either execute that thing or not. The debug counter itself
-// consists of a skip and a count. Skip is the number of times shouldExecute
-// needs to be called before it returns true. Count is the number of times to
-// return true once Skip is 0. So a skip=47, count=2 ,would skip the first 47
-// executions by returning false from shouldExecute, then execute twice, and
-// then return false again.
-// Note that a counter set to a negative number will always execute.
-
-// For a concrete example, during predicateinfo creation, the renaming pass
-// replaces each use with a renamed use.
+/// \file
+/// \brief This file provides an implementation of debug counters. Debug counters
+/// are a tool that let you narrow down a miscompilation to a specific thing
+/// happening.
///
-// If I use DEBUG_COUNTER to create a counter called "predicateinfo", and
-// variable name RenameCounter, and then instrument this renaming with a debug
-// counter, like so:
-//
-// if (!DebugCounter::shouldExecute(RenameCounter)
-// <continue or return or whatever not executing looks like>
-//
-// Now I can, from the command line, make it rename or not rename certain uses
-// by setting the skip and count.
-// So for example
-// bin/opt -debug-counter=predicateinfo-skip=47,predicateinfo-count=1
-// will skip renaming the first 47 uses, then rename one, then skip the rest.
+/// To give a use case: Imagine you have a file, very large, and you
+/// are trying to understand the minimal transformation that breaks it. Bugpoint
+/// and bisection is often helpful here in narrowing it down to a specific pass,
+/// but it's still a very large file, and a very complicated pass to try to
+/// debug. That is where debug counting steps in. You can instrument the pass
+/// with a debug counter before it does a certain thing, and depending on the
+/// counts, it will either execute that thing or not. The debug counter itself
+/// consists of a skip and a count. Skip is the number of times shouldExecute
+/// needs to be called before it returns true. Count is the number of times to
+/// return true once Skip is 0. So a skip=47, count=2 ,would skip the first 47
+/// executions by returning false from shouldExecute, then execute twice, and
+/// then return false again.
+/// Note that a counter set to a negative number will always execute.
+/// For a concrete example, during predicateinfo creation, the renaming pass
+/// replaces each use with a renamed use.
+////
+/// If I use DEBUG_COUNTER to create a counter called "predicateinfo", and
+/// variable name RenameCounter, and then instrument this renaming with a debug
+/// counter, like so:
+///
+/// if (!DebugCounter::shouldExecute(RenameCounter)
+/// <continue or return or whatever not executing looks like>
+///
+/// Now I can, from the command line, make it rename or not rename certain uses
+/// by setting the skip and count.
+/// So for example
+/// bin/opt -debug-counter=predicateinfo-skip=47,predicateinfo-count=1
+/// will skip renaming the first 47 uses, then rename one, then skip the rest.
+//===----------------------------------------------------------------------===//
#ifndef LLVM_SUPPORT_DEBUGCOUNTER_H
#define LLVM_SUPPORT_DEBUGCOUNTER_H
Modified: llvm/trunk/include/llvm/Transforms/Utils/MemorySSA.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Transforms/Utils/MemorySSA.h?rev=297505&r1=297504&r2=297505&view=diff
==============================================================================
--- llvm/trunk/include/llvm/Transforms/Utils/MemorySSA.h (original)
+++ llvm/trunk/include/llvm/Transforms/Utils/MemorySSA.h Fri Mar 10 14:44:39 2017
@@ -6,67 +6,67 @@
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
-//
-// \file
-// \brief This file exposes an interface to building/using memory SSA to
-// walk memory instructions using a use/def graph.
-//
-// Memory SSA class builds an SSA form that links together memory access
-// instructions such as loads, stores, atomics, and calls. Additionally, it does
-// a trivial form of "heap versioning" Every time the memory state changes in
-// the program, we generate a new heap version. It generates MemoryDef/Uses/Phis
-// that are overlayed on top of the existing instructions.
-//
-// As a trivial example,
-// define i32 @main() #0 {
-// entry:
-// %call = call noalias i8* @_Znwm(i64 4) #2
-// %0 = bitcast i8* %call to i32*
-// %call1 = call noalias i8* @_Znwm(i64 4) #2
-// %1 = bitcast i8* %call1 to i32*
-// store i32 5, i32* %0, align 4
-// store i32 7, i32* %1, align 4
-// %2 = load i32* %0, align 4
-// %3 = load i32* %1, align 4
-// %add = add nsw i32 %2, %3
-// ret i32 %add
-// }
-//
-// Will become
-// define i32 @main() #0 {
-// entry:
-// ; 1 = MemoryDef(0)
-// %call = call noalias i8* @_Znwm(i64 4) #3
-// %2 = bitcast i8* %call to i32*
-// ; 2 = MemoryDef(1)
-// %call1 = call noalias i8* @_Znwm(i64 4) #3
-// %4 = bitcast i8* %call1 to i32*
-// ; 3 = MemoryDef(2)
-// store i32 5, i32* %2, align 4
-// ; 4 = MemoryDef(3)
-// store i32 7, i32* %4, align 4
-// ; MemoryUse(3)
-// %7 = load i32* %2, align 4
-// ; MemoryUse(4)
-// %8 = load i32* %4, align 4
-// %add = add nsw i32 %7, %8
-// ret i32 %add
-// }
-//
-// Given this form, all the stores that could ever effect the load at %8 can be
-// gotten by using the MemoryUse associated with it, and walking from use to def
-// until you hit the top of the function.
-//
-// Each def also has a list of users associated with it, so you can walk from
-// both def to users, and users to defs. Note that we disambiguate MemoryUses,
-// but not the RHS of MemoryDefs. You can see this above at %7, which would
-// otherwise be a MemoryUse(4). Being disambiguated means that for a given
-// store, all the MemoryUses on its use lists are may-aliases of that store (but
-// the MemoryDefs on its use list may not be).
-//
-// MemoryDefs are not disambiguated because it would require multiple reaching
-// definitions, which would require multiple phis, and multiple memoryaccesses
-// per instruction.
+///
+/// \file
+/// \brief This file exposes an interface to building/using memory SSA to
+/// walk memory instructions using a use/def graph.
+///
+/// Memory SSA class builds an SSA form that links together memory access
+/// instructions such as loads, stores, atomics, and calls. Additionally, it does
+/// a trivial form of "heap versioning" Every time the memory state changes in
+/// the program, we generate a new heap version. It generates MemoryDef/Uses/Phis
+/// that are overlayed on top of the existing instructions.
+///
+/// As a trivial example,
+/// define i32 @main() #0 {
+/// entry:
+/// %call = call noalias i8* @_Znwm(i64 4) #2
+/// %0 = bitcast i8* %call to i32*
+/// %call1 = call noalias i8* @_Znwm(i64 4) #2
+/// %1 = bitcast i8* %call1 to i32*
+/// store i32 5, i32* %0, align 4
+/// store i32 7, i32* %1, align 4
+/// %2 = load i32* %0, align 4
+/// %3 = load i32* %1, align 4
+/// %add = add nsw i32 %2, %3
+/// ret i32 %add
+/// }
+///
+/// Will become
+/// define i32 @main() #0 {
+/// entry:
+/// ; 1 = MemoryDef(0)
+/// %call = call noalias i8* @_Znwm(i64 4) #3
+/// %2 = bitcast i8* %call to i32*
+/// ; 2 = MemoryDef(1)
+/// %call1 = call noalias i8* @_Znwm(i64 4) #3
+/// %4 = bitcast i8* %call1 to i32*
+/// ; 3 = MemoryDef(2)
+/// store i32 5, i32* %2, align 4
+/// ; 4 = MemoryDef(3)
+/// store i32 7, i32* %4, align 4
+/// ; MemoryUse(3)
+/// %7 = load i32* %2, align 4
+/// ; MemoryUse(4)
+/// %8 = load i32* %4, align 4
+/// %add = add nsw i32 %7, %8
+/// ret i32 %add
+/// }
+///
+/// Given this form, all the stores that could ever effect the load at %8 can be
+/// gotten by using the MemoryUse associated with it, and walking from use to def
+/// until you hit the top of the function.
+///
+/// Each def also has a list of users associated with it, so you can walk from
+/// both def to users, and users to defs. Note that we disambiguate MemoryUses,
+/// but not the RHS of MemoryDefs. You can see this above at %7, which would
+/// otherwise be a MemoryUse(4). Being disambiguated means that for a given
+/// store, all the MemoryUses on its use lists are may-aliases of that store (but
+/// the MemoryDefs on its use list may not be).
+///
+/// MemoryDefs are not disambiguated because it would require multiple reaching
+/// definitions, which would require multiple phis, and multiple memoryaccesses
+/// per instruction.
//===----------------------------------------------------------------------===//
#ifndef LLVM_TRANSFORMS_UTILS_MEMORYSSA_H
Modified: llvm/trunk/include/llvm/Transforms/Utils/PredicateInfo.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Transforms/Utils/PredicateInfo.h?rev=297505&r1=297504&r2=297505&view=diff
==============================================================================
--- llvm/trunk/include/llvm/Transforms/Utils/PredicateInfo.h (original)
+++ llvm/trunk/include/llvm/Transforms/Utils/PredicateInfo.h Fri Mar 10 14:44:39 2017
@@ -6,47 +6,46 @@
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
-//
-// \file
-// \brief
-//
-// This file implements the PredicateInfo analysis, which creates an Extended
-// SSA form for operations used in branch comparisons and llvm.assume
-// comparisons. Copies of these operations are inserted into the true/false
-// edge (and after assumes), and information attached to the copies. All uses
-// of the original operation in blocks dominated by the true/false edge (and
-// assume), are replaced with uses of the copies. This enables passes to easily
-// and sparsely propagate condition based info into the operations that may be
-// affected.
-//
-// Example:
-// %cmp = icmp eq i32 %x, 50
-// br i1 %cmp, label %true, label %false
-// true:
-// ret i32 %x
-// false:
-// ret i32 1
-//
-// will become
-//
-// %cmp = icmp eq i32, %x, 50
-// br i1 %cmp, label %true, label %false
-// true:
-// %x.0 = call @llvm.ssa_copy.i32(i32 %x)
-// ret i32 %x.0
-// false:
-// ret i32 1
-//
-// Using getPredicateInfoFor on x.0 will give you the comparison it is
-// dominated by (the icmp), and that you are located in the true edge of that
-// comparison, which tells you x.0 is 50.
-//
-// In order to reduce the number of copies inserted, predicateinfo is only
-// inserted where it would actually be live. This means if there are no uses of
-// an operation dominated by the branch edges, or by an assume, the associated
-// predicate info is never inserted.
-//
-//
+///
+/// \file
+/// \brief This file implements the PredicateInfo analysis, which creates an Extended
+/// SSA form for operations used in branch comparisons and llvm.assume
+/// comparisons.
+///
+/// Copies of these operations are inserted into the true/false edge (and after
+/// assumes), and information attached to the copies. All uses of the original
+/// operation in blocks dominated by the true/false edge (and assume), are
+/// replaced with uses of the copies. This enables passes to easily and sparsely
+/// propagate condition based info into the operations that may be affected.
+///
+/// Example:
+/// %cmp = icmp eq i32 %x, 50
+/// br i1 %cmp, label %true, label %false
+/// true:
+/// ret i32 %x
+/// false:
+/// ret i32 1
+///
+/// will become
+///
+/// %cmp = icmp eq i32, %x, 50
+/// br i1 %cmp, label %true, label %false
+/// true:
+/// %x.0 = call @llvm.ssa_copy.i32(i32 %x)
+/// ret i32 %x.0
+/// false:
+/// ret i32 1
+///
+/// Using getPredicateInfoFor on x.0 will give you the comparison it is
+/// dominated by (the icmp), and that you are located in the true edge of that
+/// comparison, which tells you x.0 is 50.
+///
+/// In order to reduce the number of copies inserted, predicateinfo is only
+/// inserted where it would actually be live. This means if there are no uses of
+/// an operation dominated by the branch edges, or by an assume, the associated
+/// predicate info is never inserted.
+///
+///
//===----------------------------------------------------------------------===//
#ifndef LLVM_TRANSFORMS_UTILS_PREDICATEINFO_H
More information about the llvm-commits
mailing list