llvm-project/flang/lib/Semantics/unparse-with-symbols.cpp

97 lines
3.4 KiB
C++
Raw Normal View History

//===-- lib/Semantics/unparse-with-symbols.cpp ----------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
#include "flang/Semantics/unparse-with-symbols.h"
#include "flang/Parser/parse-tree-visitor.h"
#include "flang/Parser/parse-tree.h"
#include "flang/Parser/unparse.h"
#include "flang/Semantics/symbol.h"
#include "llvm/Support/raw_ostream.h"
#include <map>
#include <set>
namespace Fortran::semantics {
// Walk the parse tree and collection information about which statements
// reference symbols. Then PrintSymbols outputs information by statement.
// The first reference to a symbol is treated as its definition and more
// information is included.
class SymbolDumpVisitor {
public:
// Write out symbols referenced at this statement.
void PrintSymbols(const parser::CharBlock &, llvm::raw_ostream &, int);
template<typename T> bool Pre(const T &) { return true; }
template<typename T> void Post(const T &) {}
template<typename T> bool Pre(const parser::Statement<T> &stmt) {
currStmt_ = stmt.source;
return true;
}
template<typename T> void Post(const parser::Statement<T> &) {
currStmt_ = std::nullopt;
}
[flang] [OpenMP] OmpVisitor framework for Name Resolution This is a preliminary framework to do the name resolution for data references on the OpenMP clauses. Unlike data references in the OpenMP region, clauses determining the data-sharing or data-mapping attributes are straightforward and the resolution process could be extended to do the name resolution in the OpenMP region. It is hard to determine what kind of checks can be done in this visitor and what checks should be done later after name resolution. But the guide line is that `After the completion of this phase, every Name corresponds to a Symbol with proper OpenMP attribute(s) determined unless an error occurred.` 1. Take data-sharing clauses as example, create new symbol for variable that require private access within the OpenMP region. Declare the entity implicitly if necessary. The new symbol has `HostAssocDetails`, which is mentioned in the `OpenMP-semantics.md`. 2. For `Shared` or `ThreadPrivate`, no symbol needs to be created. OpenMP attribute Flag `OmpThreadprivate` needs to be marked for `Threadprivate` because the `threadprivate` attribute remains the same whenever these variables are referenced in the program. `Names` in `Shared` clause need to be resolved to associate the symbols in the clause enclosing scope (contains the OpenMP directive) but `OmpShared` does not need to be marked. Declare the entity implicitly if necessary. 3. For `COMMON block`, when a named common block appears in a list, it has the same meaning as if every explicit member of the common block appeared in the list. Also, a common block name specified in a data-sharing attribute clause must be declared to be a common block in the same scoping unit in which the data-sharing attribute clause appears. So, if a named common block appears on a `PRIVATE` clause, all its members should have new symbols created within the OpenMP region (scope). For later Semantic checks and CG, a new symbol is also created for common block name with `HostAssocDetails`. There are many things are still on the TODO list: - Better error/warning messages with directive/clause source provenance - Resolve variables referenced in the OpenMP region, for example, `private(tt%a)` is not allowed but `tt%a = 1` is allowed in the OpenMP region and a private version of `tt` maybe created for the region. The functions created in the `OmpVisitor` should be able to handle the name resolution on the statement too (more data structures may be introduced). This is a big portion and may require some interface changes to distinguish a reference is on `OpenMP directive/clause` or `statements within OpenMP region`. - Same data reference appears on multiple data-sharing clauses. - Take association into consideration for example Pointer association, `ASSOCIATE` construct, and etc. - Handle `Array Sections` and `Array or Structure Element`. - Handle all the name resolution for directives/clauses that have `parser::Name`. - More tests Original-commit: flang-compiler/f18@b2ea520885eceb6e118f690b95e1846183fe378b
2019-09-12 05:42:51 +08:00
bool Pre(const parser::OmpClause &clause) {
currStmt_ = clause.source;
return true;
}
void Post(const parser::OmpClause &) { currStmt_ = std::nullopt; }
bool Pre(const parser::OpenMPThreadprivate &dir) {
currStmt_ = dir.source;
return true;
}
void Post(const parser::OpenMPThreadprivate &) { currStmt_ = std::nullopt; }
void Post(const parser::Name &name);
private:
std::optional<SourceName> currStmt_; // current statement we are processing
std::multimap<const char *, const Symbol *> symbols_; // location to symbol
std::set<const Symbol *> symbolsDefined_; // symbols that have been processed
void Indent(llvm::raw_ostream &, int) const;
};
void SymbolDumpVisitor::PrintSymbols(
const parser::CharBlock &location, llvm::raw_ostream &out, int indent) {
std::set<const Symbol *> done; // prevent duplicates on this line
auto range{symbols_.equal_range(location.begin())};
for (auto it{range.first}; it != range.second; ++it) {
const auto *symbol{it->second};
if (done.insert(symbol).second) {
bool firstTime{symbolsDefined_.insert(symbol).second};
Indent(out, indent);
out << '!' << (firstTime ? "DEF"s : "REF"s) << ": ";
DumpForUnparse(out, *symbol, firstTime);
out << '\n';
}
}
}
void SymbolDumpVisitor::Indent(llvm::raw_ostream &out, int indent) const {
for (int i{0}; i < indent; ++i) {
out << ' ';
}
}
void SymbolDumpVisitor::Post(const parser::Name &name) {
if (const auto *symbol{name.symbol}) {
[flang] Change when symbol is set in parser::Name Rework how `parser::Name` is resolved to contain a `Symbol`. so that constants in types can be evaluated. For example: ``` integer, parameter :: k = 8 integer(k) :: i ``` The old approach of collecting the symbols at the end of name resolution and filling in the `parser::Name` does not work because the type of `i` needs to be set in the symbol table. The symbol field in `parser::Name` is now mutable so that we can set it during name resolution. `RewriteParseTree` no longer needs to do that (it still warns about unresolved ones), so it does not need to collect symbols and fill them in. Consequently, we can eliminate "occurrences" from symbols -- we just need the name where each is first defined. This requires a lot of refactoring in `resolve-names.cc` to pass around `parser::Name` rather than `SourceName` so that we can resolve the name to a symbol. Fix some bugs where we stored `SourceName *` instead of `SourceName` in the symbol table. The pointers were into the parse tree, so they were only valid as long as the parse tree was around. The symbol table needs to remain valid longer than that, so the names need to be copied. `parser::Name` is not used in the symbol table. Eliminate `GenericSpec`. Currently all we need to do is to resolve the kinds of GenericSpec that contain names. Add `ScopeName` kind of `MiscDetails` for when we need a symbol in the scope to match the name of the scope. For example, `module m` cannot contain a declaration of a new `m`. Subprograms need real details because they can be called recursively. Fix output of partially resolved modules where we know it is a submodule but have not yet resolved the ancestor. Original-commit: flang-compiler/f18@5c1a4b99d2421f5b32e83426488d3fdf7951cfba Reviewed-on: https://github.com/flang-compiler/f18/pull/238 Tree-same-pre-rewrite: false
2018-11-17 04:43:08 +08:00
if (!symbol->has<MiscDetails>()) {
symbols_.emplace(currStmt_.value().begin(), symbol);
[flang] Change when symbol is set in parser::Name Rework how `parser::Name` is resolved to contain a `Symbol`. so that constants in types can be evaluated. For example: ``` integer, parameter :: k = 8 integer(k) :: i ``` The old approach of collecting the symbols at the end of name resolution and filling in the `parser::Name` does not work because the type of `i` needs to be set in the symbol table. The symbol field in `parser::Name` is now mutable so that we can set it during name resolution. `RewriteParseTree` no longer needs to do that (it still warns about unresolved ones), so it does not need to collect symbols and fill them in. Consequently, we can eliminate "occurrences" from symbols -- we just need the name where each is first defined. This requires a lot of refactoring in `resolve-names.cc` to pass around `parser::Name` rather than `SourceName` so that we can resolve the name to a symbol. Fix some bugs where we stored `SourceName *` instead of `SourceName` in the symbol table. The pointers were into the parse tree, so they were only valid as long as the parse tree was around. The symbol table needs to remain valid longer than that, so the names need to be copied. `parser::Name` is not used in the symbol table. Eliminate `GenericSpec`. Currently all we need to do is to resolve the kinds of GenericSpec that contain names. Add `ScopeName` kind of `MiscDetails` for when we need a symbol in the scope to match the name of the scope. For example, `module m` cannot contain a declaration of a new `m`. Subprograms need real details because they can be called recursively. Fix output of partially resolved modules where we know it is a submodule but have not yet resolved the ancestor. Original-commit: flang-compiler/f18@5c1a4b99d2421f5b32e83426488d3fdf7951cfba Reviewed-on: https://github.com/flang-compiler/f18/pull/238 Tree-same-pre-rewrite: false
2018-11-17 04:43:08 +08:00
}
}
}
void UnparseWithSymbols(llvm::raw_ostream &out, const parser::Program &program,
parser::Encoding encoding) {
SymbolDumpVisitor visitor;
parser::Walk(program, visitor);
parser::preStatementType preStatement{
[&](const parser::CharBlock &location, llvm::raw_ostream &out,
int indent) { visitor.PrintSymbols(location, out, indent); }};
parser::Unparse(out, program, encoding, false, true, &preStatement);
}
}