#include <mapping_options.pb.h>
#include <array>
#include <iostream>
#include <string>
#include <vector>
#include "tc/external/isl.h"
#include "tc/core/flags.h"
#include "tc/core/rtc.h"
#include "tc/core/mapping_options-inl.h"

Include dependency graph for mapping_options.h:

This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Classes
class	tc::ValueAccessor< T >

class	tc::CudaDimView

class	tc::CudaDim

class	tc::Block
	Specializing CudaDim to differentiate between Block and Grid sizes. More...

class	tc::Grid
	Specializing CudaDim to differentiate between Block and Grid sizes. More...

class	tc::TilingView

class	tc::Tiling
	"Materialized" TilingView. More...

class	tc::SchedulerOptionsView

class	tc::SchedulerOptions
	"Materialized" SchedulerOptionsView. More...

class	tc::MappingOptions

Namespaces
	tc

	tc::callbacks

Functions
__isl_give isl_basic_set *	tc::callbacks::AddPositiveCoefficientConstraints (__isl_take isl_basic_set lp, int n_param, int dim, __isl_keep isl_id_list stmt_ids, int node_n_params, int node_n_dims, void *)

isl_bool	tc::callbacks::FuseAllPreserve3Coincident (__isl_take isl_union_map original_schedule, __isl_take isl_union_map updated_schedule, int n_updated_coincident, int n_original_coincident, int is_along_edge, void *)

isl_bool	tc::callbacks::FuseAll (__isl_take isl_union_map original_schedule, __isl_take isl_union_map updated_schedule, int n_updated_coincident, int n_original_coincident, int is_along_edge, void *)

isl_bool	tc::callbacks::FuseNone (__isl_take isl_union_map original_schedule, __isl_take isl_union_map updated_schedule, int n_updated_coincident, int n_original_coincident, int is_along_edge, void *)

Detailed Description

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. A set of classes that act as the in-memory interface to control polyhedral scheduling and mapping. Storage is provided by protocol buffers.

The interface is based on a concept of "view" classes that provide a different interface to (parts of) underlying protocol buffers. Each view has a mutable reference to a protocol buffer message, which may be a part of a larger message. It also provides a set of convenience functions to inspect and modify the underlying message. All modifications are immediately stored in the protocol buffers, up to the top-level message. Because views only represent a (part of a) message, which they do not own, they cannot be constructed from values. However, they can be copy-constructed, with a copy referring to the same underlying object, and assigned, with all fields of the underlying object assigned. Views can be constructed given a protocol buffer message, to which they hold a reference. The caller is responsible for ensuring the actual message lives at least as long as the view.

All views come with a "materialized" counterpart that owns the underlying message. They can be constructed from a set of values, from another view or from a protocol buffer. In the two latter cases, they make a deep copy of the message. "Materialized" view classes derive from views making it possible to assign a view referring to a part of top-level message from a "materialized" temporary. For example,

MappingOptions mo;
// Copy of a view refers to the same object.
CudaDimView view = mo.block;
// Ultimately assigns mo.proto.mutable_block.
view = CudaDim(42, 100, 2);

is equivalent to

MappingOptions mo;
mo.proto.mutable_block()->set_x(42);
mo.proto.mutable_block()->set_y(100);
mo.proto.mutable_block()->set_z(2);

References to underlying protocol buffers message objects are exposed publicly. They can be changed directly, and changes are immediately visible through all views referring to (a part of) the message. For example,

MappingOptions mo;
mo.proto.mutable_block()->set_x(42);
cout << mo.block[0];    // outputs 42;

"Materialized" views do not expose the message they own, only a modifiable reference through the view interface.

The top-level interface (MappingOptions) owns and publicly exposes the top-level protocol buffer message along with views to its sub-messages.

Classes

Namespaces

Functions

Detailed Description