[cfe-dev] Optimization of arithmetic expressions involving user-defined C++ objects
Michael Kruse via cfe-dev
cfe-dev at lists.llvm.org
Fri Apr 17 20:11:22 PDT 2020
LLVM has its predetermined set of types of instructions
(https://llvm.org/docs/LangRef.html) and optimizations look for
specific instructions that it can be applied to, instead of its
properties. Hence, it is not possible to apply the same optimization
on user-implemented types and operations.
This might change with MLIR which has extendable types and operations
and optimizations might be more guided by an operation property. For
instance, there is mlir::OperationProperty::Commutative so
optimization passes use this property instead of just knowing all the
instructions that are commutative.
Sadly, commutativity is (currently) the only semantic property of
Another item to consider is, once you implemented a custom type and
operators in C++, how does the compiler know about its properties.
There is no C++ API to make the compiler know.
Am Di., 14. Apr. 2020 um 07:20 Uhr schrieb ardi via cfe-dev
<cfe-dev at lists.llvm.org>:
> AFAIK, there's no C++ syntax for letting know the compiler that the
> operators in your classes exactly match the same meaning as some
> built-in type. So, if for example you write a class that implements
> IEEE fp math in software, the compiler won't have the chance of
> transforming the expression into a different one that has the same
> result with a lower computation cost (*).
> Given that LLVM is hackable by nature, is there some workaround by
> which I could tell clang "consider the operators for this class with
> the same optimization opportunities as this other built-in type" ?
> Alternatively, does LLVM have any tool (or do you know of any outside
> LLVM) that would allow to perform static optimization of an arithmetic
> expression and transform the code, similar to a preprocessor step?
> (*) Note: I acknowledge that even if the operators had the same
> meaning as a built-in type, maybe their relative cost would be
> different, so, ideally it wouldn't be a matter of just telling the
> meaning of the operator, but also its relative cost.
> Thanks a lot,
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
More information about the cfe-dev